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. Watch out for autocomplete widgets, where keyboard focus may get stuck.
īeware of completely trapping focus at any point. See Managing Focus at the Page Level for examples. If new content is added to the page, try to make sure that the user’s focus is directed to that content so they can take action on it. For screen reader users, the screen reader will already announce these headings, so there’s no need to make them focusable. This is also an anti-pattern because it makes keyboard users who can see the screen less efficient. Sometimes developers add a tabindex to headings because they think they’re important. Non-interactive content (e.g., headings) should avoid being focusable. This can be confusing for screen reader users as they tend to navigate the DOM in a linear fashion. These controls will jump ahead of everything else in the tab order, regardless of their position in the DOM. To make a custom control focusable, give it a tabindex="0". If you use JavaScript to turn a into a fancy dropdown, it will not automatically be inserted into the tab order. Ĭustom interactive controls should aim to be focusable. If you need to differentiate between mouse and keyboard focus for styling, consider adding a library like what-input. If a keyboard user can’t see what’s focused, they have no way of interacting with the page. It’s common practice to disable focus styles without providing an alternative by using outline: none in CSS, but this is an anti-pattern. The general rule of thumb is that any control a user can interact with or provide input to should aim to be focusable and display a focus indicator (e.g., a focus ring). If you’re unsure which elements should receive focus, see Focus Fundamentals for a refresher. The order in which elements are focused should aim to follow the DOM order. For a good keyboarding experience aim to have a logical tab order and easily discernable focus styles. This audience includes users with motor impairments, such as Repetitive Stress Injury (RSI) or paralysis, as well as screen reader users. Start with the keyboard #įor users who either cannot or choose not to use a mouse, keyboard navigation is their primary means of reaching everything on screen. In this post, I'm going to break down these issues into a logical, step by step process for reviewing an existing site for accessibility. 
If you are approaching accessibility for the first time, the sheer breadth of the topic can leave you wondering where to start - after all, working to accommodate a diverse range of abilities means there are a correspondingly diverse range of issues to consider. Determining if your web site or application is accessible can seem like an overwhelming task.
0 kommentar(er)
