Is it good or bad?
With great power comes great responsibility
Web content accessibility is about the quality of the markup, where the HTML is king. The document structure must convey information in a logical and straightforward way, plus the markup should be semantic. It should provide all the information users of assistive technologies need to get a solid grasp of the content and purpose of a document. It should give all the available actions, plus provide the necessary feedback.
Technology doesn’t matter
In the same way, developers should build React user interface controls using semantic HTML. I’ve seen components using wrong elements and events, though. Buttons that are not real buttons but span elements, DOM events that don’t work when using a keyboard, and so on. This is not a limitation of React, though, it’s an implementation that can be improved.
Developers can produce poorly structured and non-semantic HTML using any language. Again, developers must structure their application’s markup using semantic elements. Also, they must avoid introducing accessibility barriers.
A couple of recommended best practices
Avoid continuous re-rendering
When using a keyboard or a screen reader, navigating through content is a linearized process. With a keyboard, users can tab through focusable elements in the order they’re in the markup. Screen readers offer several shortcuts to jump to different sections of a web page, but navigation is still linearized. So, when a portion of the DOM gets re-rendered, developers should take special care to handle the browser and screen reader “focus”. They’re two slightly different concepts (not entering into technical details now). Developers need to know that there’s a high chance of a focus loss.
Loss of focus
When a portion of a web page gets re-rendered, it often gets completely removed from the DOM and then injected again with a new state and data. Visually, this happens so fast that is hardly noticeable. By the way, when the keyboard focus or the screen reader “focus” is within the re-rendered region, then in the exact moment that part of the DOM gets removed, the focused element gets removed too. Browsers won’t know where to put focus anymore. So, keyboard and screen reader users will lose the context. They will be forced to start navigating content from scratch or a place in the user interface browsers will “think” is the right place to put focus on.
Sometimes this kind of focus loss is so severe that it makes an application impossible to use with a keyboard or a screen reader. There are ways to mitigate this issue. For one, you should always test your application using a keyboard. When a DOM update is necessary, then focus should be programmatically handled in a logical way, moving or restoring focus in a proper place.
DOM events may not work as you expect
When using a screen reader, DOM events, especially keyboard events, may not work as you expect. To understand why this happens, developers should be aware of screen reader interaction modes. They should pay extra attention to Windows screen readers. Understanding what virtual/browse mode and forms/focus mode do help to avoid common mistakes that make content inaccessible to screen readers. VoiceOver on macOS has a different interaction model compared to Windows screen readers. What developers need to know is that all screen readers intercept keypresses before they reach the browser. However, there are a few exceptions like the tab key or when the enter key is used to activate a link.
When in virtual/browse mode, screen readers use keypresses for their own purposes, to offer users several commands and shortcuts to navigate content. Screen readers switch to forms/focus mode when necessary, for example within a form, to pass back keypresses to the browser.
When operating within a form, users need keypresses to type in the form fields. They also need it to move the cursor inside the typed text, select the typed text, activate other form controls, and so on. Instead, when in virtual/browse mode, the browser is unaware a keyboard event occurred. There’s no event fired at all. This switch mechanism works pretty well with native HTML elements because screen readers know what to expect from these elements.
However, when it comes to custom/rich internet widgets, there’s a chance to introduce accessibility barriers. In this context, a custom widget is anything that is not “native” HTML. This could be a user interface component with an interaction model that is not standard and can’t be predicted by the markup.
Say we’ve built a user interface component that relies on some keydown events attached to items in a list. It could be a menubar or a tab set. Since list items are not natively focusable and don’t natively support keyboard interaction, screen readers will stay in virtual/browse mode. They have no reason to switch to forms/focus mode. So all our keydown events won’t fire at all. This can be surprising at first. Everything functions nicely in a browser, but when a screen reader is running, everything stops working.
The solution is to let screen readers know they have to switch interaction mode. Pass keypresses back to the browser so that they can fulfill their original purpose. As a best practice, you should always prefer elements that have native support for keyboard interaction to other elements. Screen readers know what a button is and they’ll behave correctly. When using other elements, then a proper use of ARIA roles is the solution. Certain ARIA roles, when applied to custom widgets, inform screen readers that HTML elements have a specific purpose. Besides that, they’ll inform that virtual/browse mode is not appropriate. The result is that screen readers will pass back keypresses to the browser as required by the specified ARIA role, thus making our custom widget work properly.
Exploring new territories
Want to help?
Accessibility is a process based on continuous improvements, testing, iteration, and development. You can help. We’re always open to feedback and contributions. Please do not hesitate to let us hear your voice. Do report any issues or potential improvements you notice in our products.