Media player accessibility is essential for video content. Evaluate the accessibility and cross-device compatibility of the media player that comes with your video-distribution platform. Test the player in different platforms and devices to evaluate the user experience it provides out of the box.... Read more about ✎ Technique: Choosing a media player

Autocomplete widgets can be helpful for accessibility because they can make it easier to enter text by providing suggestions based on the characters initially typed. This particularly helps people who find typing more difficult and people who may be susceptible to spelling mistakes.

Creating an accessible integrated autocomplete widget is a complex process. You need to ensure that screen-reader users are notified when the list of suggestions appears and that they can enter the list and select an option...

For a number of reasons including data persistence, performance and security, it is sometimes beneficial to terminate idle user sessions.

So that users do not lose data, it's important to warn them of a session that is about to expire and give them the option to continue. This is especially true in the case of people who might take longer to read or interact with a page due to a disability. It's important to make such prompts accessible.

Modal dialogs can enhance usability by focusing attention on a specific message that requires a user action to continue.

An accessible modal dialog is one where keyboard focus is managed properly, and the correct information is exposed to screen readers. HTML and WAI-ARIA can be used to provide the necessary semantic information, CSS the appearance and Javascript the behavior.

Expandables (sometimes called “collapsible” or “disclosure widgets”) are simple interface patterns that allow you to expand and collapse content. They can be helpful accessibility aids as they give users the choice of revealing content to read it, or bypassing the content, making page navigation more efficient for screen-reader users and people using the keyboard or alternative input devices.

To ensure that they are accessible, it's important that expandable sections are coded so that their state (...

Interactive elements should, under most circumstances, be focusable in the order that they appear in the source code. This helps people who are using the keyboard or alternative input devices to follow focus in a logical order.

The order that elements appear in the document source should reflect the order they appear visually.

All interactive elements should be focusable so that they can be activated using a mouse, a keyboard, voice recognition software, a switch input device, and other input methods.

They should also indicate when they’re focused so that users know which element they are currently interacting with. This is where focus styles come into play.

Sometimes, design requirements mean that you need to create an interactive element from a base <div> element or a custom element like <my-button> rather than using a native HTML element.

Your element will not be accessible by keyboard unless it is included in focus order and it can be activated using the ENTER and SPACE keys.

Links (<a> elements) are focusable by default, so it should normally be possible to activate them using the keyboard. However, under certain circumstances, they are not focusable: Unless you are deliberately trying to "disable" a link, make sure it does not take the form of any of these examples.

When positioning elements using CSS, it's possible to place them in a position that does not reflect their location in the source order. This can have unexpected side effects for keyboard-navigation users.