Recently, I listened to an episode of the podcast Javascript Jabber with Bruce Lawson, who has been a big figure in the semantic HTML movement. Lawson makes the case the semantic HTML (think <article> or <main> instead of just <div> or ) is not only good for accessibility, but that more accessible web sites are good for business. This makes sense: more people can use the site or application optimizing it for screen readers or people who cannot use a mouse.
It is crucial to remember the inherent biases to a mostly visual medium like the internet, and the blocks that can have to accessibility. A few years ago, I remember reading that many art galleries in New York were sued for not have accessible web sites. This was part of a rise in lawsuits related to websites and the Americans With Disabilities Act, which raises a good question to constantly ask yourself as a developer: am I doing the best I can to make my site accessible, and are the tools I am using helping me do that?
One thing that stuck with me was an antipathy that Lawson voiced toward Javascript frameworks. This was about the constant proliferation of frameworks but also about the failure of many of these to incorporate semantic HTML. Working in React for a few weeks now and writing <div> after <div>, I began to think about Lawson some more and investigate what would a more accessible version of React look like.
React is not inherently anti-accessibility. The issue is more about best practices in using React and how these might be implemented. (Hint: don’t go crazy with the div tags). React’s documentation is a great resource for how to implement a more accessible version of the framework.
Using Semantic HTML
According to Lawson, one of the best things we can do when writing code is to actually take advantage of the semantic HTML options. Footer, header, section, and article are all important and easy to incorporate in the render function of different components, optimizing the DOM readability for screen readers. Although this requires a shift in behavior from all the div tags, it is a good first step in promoting accessibility.
Fragments
Fragments are another important way to promote accessible code. Div tags themselves might not necessarily by a problem, but the proliferation of div tags on a page can start to cause problems for screen readers, bogging them down in too many nest <div> tags. It is accepted that fragments are best practices in React, and it is also a case where a best practice has ramifications far beyond clean code.
ARIA Attributes
ARIA is an acronym for Accessible Rich Internet Applications. Mozilla’s documentation provides a good definition of ARIA’s three types: roles, states, and properties.
Roles describe widgets that aren’t otherwise available in HTML 4, such as sliders, menu bars, tabs, and dialogs. Properties describe characteristics of these widgets, such as if they are draggable, have a required element, or have a popup associated with them. States describe the current interaction state of an element, informing the assistive technology if it is busy, disabled, selected, or hidden.
There are a lot of cases where ARIA attributes are not entirely necessary in React, where functionality is explicit or logically implicit (say a search button with a submit button labelled search next to it, well input fields that make good use of labels—i.e. good semantic HTML). In other cases, it is very easy to add ARIA attributes, though unlike most things in JSX, these attributes are written in a hyphen case (e.g. aria-label={labelText} ) rather than camel case.
Although the tools were use are never neutral, it is always important to remember their impact depends on how we wield them.
Top comments (0)