Website and web app accessibility

Some users are physically unable to use a mouse and might be navigating through the page using a keyboard only.

Testing a website with a keyboard requires no special tools or skills, just use the Tab key to navigate, without the mouse. As you do this, consider these questions:

• Is a visual indication of keyboard focus present at all times?
• Can you access all features?
• Can you operate all controls?
• Is it reasonably easy to tell where you are on the page?
• When new content is added to or exposed on the page, can the user act on it?

Non-interactive content (for example, plain text and headings) should not be focusable with keyboard alone. Screen readers will still include plain text in the reading order, so there’s no need to make that content focusable.

Beware of completely trapping focus at any point. Watch out for autocomplete widgets, where keyboard focus may get stuck. Focus can be temporarily trapped in specific situations, such as displaying a modal, when you don’t want the user interacting with the rest of the page — but you should aim to provide a keyboard-accessible method of escaping the modal as well.

In addition to visual and auditory feedback, users who rely on keyboard navigation must also be able to access and manipulate updated content if required. Additionally, any time you have a hover event — “:onhover” — ensure that you pair it with a focus event — “:onfocus” — so that either action takes users to the same place.

Website navigation menus often include dropdown or flyout menus, where submenus are hidden by default and appear visibly when mouse users hover over or click a top-level menu item. These sorts of menus can present major accessibility challenges for many groups of users unless they are coded properly. Accessibility specialists have explored this problem in depth, with recommendations.

The UW Theme for WordPress includes an accessibility-designed navigation menu, and the university encourages all website owners to use it.

Make your online forms easy for everyone to use. Give each form field a clear and accurate label or prompt. People who see the form can tell which label goes with which box, but screen reader users can’t unless you connect each label to its box in the form’s code. This helps all users understand what information to enter where.

When a link or button on your website will load new content or take the user to a new page, load new content in the same tab. This can help avoid disorienting users by moving their focus into a new window or tab.
There are some exceptions, for example if a user would lose progress in a form by loading new content or if the user needs to login or verify their identity while performing an action. In this case, warn users with an ARIA label or link text that the content will open in a new tab or window.