{ "componentChunkName": "component---src-templates-post-js", "path": "/web-accessibility-a11y-using-reactjs/", "result": {"data":{"markdownRemark":{"html":"

Achieving Accessibility in React Applications

\n

a11y stands for ACCESSIBILITY\nThe phrase '11 characters'. Arrows are pointing to the first letter c and the letter t in the word 'accessibility' to show how the numeronym is formed.\nThe A11Y Project is a community-driven effort to make digital accessibility easier.

\n

What is accessibility?

\n

This article starts off the module with a good look at what accessibility actually is — this includes what groups of people we need to consider and why, what tools different people use to interact with the Web, and how we can make accessibility part of our web development workflow.

\n

HTML: A good basis for accessibility

\n

A great deal of web content can be made accessible just by making sure that the correct HTML elements are used for the correct purpose at all times. This article looks in detail at how HTML can be used to ensure maximum accessibility.

\n

CSS and JavaScript accessibility best practices

\n

CSS and JavaScript, when used properly, also have the potential to allow for accessible web experiences. They can significantly harm accessibility if misused. This article outlines some CSS and JavaScript best practices that should be considered to ensure that even complex content is as accessible as possible.

\n

WAI-ARIA basics

\n

Following on from the previous article, sometimes making complex UI controls that involve unsemantic HTML and dynamic JavaScript-updated content can be difficult. WAI-ARIA is a technology that can help with such problems by adding in further semantics that browsers and assistive technologies can recognize and let users know what is going on. Here we'll show how to use it at a basic level to improve accessibility.

\n

Accessible multimedia

\n

Another category of content that can create accessibility problems is multimedia — video, audio, and image content need to be given proper textual alternatives so that they can be understood by assistive technologies and their users. This article shows how.

\n

Mobile accessibility

\n

With web access on mobile devices being so popular and popular platforms such as iOS and Android having fully-fledged accessibility tools, it is important to consider the accessibility of your web content on these platforms. This article looks at mobile-specific accessibility considerations.

\n

What is Web Accessibility (A11y)

\n

Web Accessibility is the design of pages, tools and technologies on the web that can be used by everyone. Everyone here includes people with auditory, cognitive, neurological, physical, speech and visual disabilities. Accessibility support is necessary to allow assistive technology to interpret web pages and applications.

\n

A11y is a numero-nym that stands for accessibility as “a\" followed by 11 more letters, followed by “y\". Web development with accessibility in mind, ensures total inclusion of the entire population that use the web.

\n

Why Web Accessibility

\n

Web Accessibility as a feature has been seen as a very wrong way of design thinking because by default it excludes a large number of web users. People who cannot see or for some reason cannot use a trackpad or a mouse pointer for instance should have as much rights and access as people who can. Inclusive design starts by thinking about every web user equally, this would easily make you see web accessibility as a must and not a feature. Web accessibility also benefits people without disabilities, these people may include:

\n\n

Accessibility Standards and Guidelines

\n

These are guidelines that govern how accessibility is achieved while building for and using the web. These ensure that there is support for screen readers, keyboard usability and captions for photos. Some of them are:

\n

WCAG: The Web Content Accessibility Guidelines provides guidelines for creating accessible web sites. WCAG is developed through the W3C process in cooperation with individuals and organisations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organisations, and governments internationally.

\n

WAI-ARIA: The Web Accessibility Initiative — Accessible Rich Internet Applications document contains techniques for building fully accessible JavaScript widgets. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies like React.

\n

Barrier to Building Accessible JS Framework Apps..

\n

I would argue that the most dominant issue we have when trying to build accessible apps is caused by developers writing non-semantic code. Using JSX in inefficient ways that when compiled, the code would not be exactly semantic HTML. And we know that whenever there is non semantic HTML, assistive technologies like screen readers find it difficult to parse the content as it was intended. This process ends up in making the apps non-accessible.

\n
    \n
  1. Casing and Reserved Words
    2. \n
\n

=================================

\n

Writing semantic HTML in your React components would require that you pay attention to casing of attributes. In react, most HTML attributes are written in camel case.

\n

maxlength becomes maxLengthtabindex becomes tabIndexcontenteditable becomes contentEditable

\n

However, all aria-* HTML attributes are fully supported in JSX these attributes should be hyphen-cased kebab-cased as they are in plain HTML:

\n

aria-label={labelText}
\naria-required=\"true\"

\n

For reserved words, we have that some reserved words mean entirely different things in HTML and in javascript words like class and for are practical examples, so in React we change them like thus:

\n

for becomes htmlForclass becomes className

\n
    \n
  1. Setting Page Titles
    2. \n
\n

===========================

\n

Setting the page title is another very powerful step to making your react application very accessible. It is actually crucial for screen readers, the page title is the first thing screen readers announce. It updates the content currently showing in the browser tab helping to announce exactly where the users (who might depend on screen readers) are in your application. It is also really great for search engine optimisation. It is done like this:

\n

componentDidMount() { document.title = “this is the page title\";}

\n

There is also a plugin you can use instead, react-helmet where you essentially handle head tags per page/component. This can be done like this:

\n
import React from \"react\";  \nimport {Helmet} from \"react-helmet\";  \n  \nclass Application extends React.Component {  \n  render () {  \n    return (  \n        <div className=\"application\">  \n            <Helmet>  \n                <meta charSet=\"utf-8\" />  \n                <title>My Title</title>  \n                <link rel=\"canonical\" href=\"http://mysite.com/example\" />  \n            </Helmet>  \n            ...  \n        </div>  \n    );  \n  }  \n};
\n
    \n
  1. Write Semantic HTML
    2. \n
\n

=======================

\n

To ensure that every code block of yours is going to be accessible, write good HTML code. We all make the quick button mistake:

\n
Click on me
\n

This would render a button, but it is not an accessible HTML button, a screen reader would not be able to interpret this. A more accessible and semantic code that does the same thing is this:

\n

\n
    \n
  1. Never Forget the text Alt of any content
    2. \n
\n

================================================

\n

This is very important for every non-text content. Text is the most optimal format for any content, so make sure to add text alternatives. For images, use the alt:

\n\"\n
\n

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose — Ire Aderinokun

\n
\n

For user interfaces, use labels:

\n
<div role=\"navigation\" aria-label=\"Primary\">  \n  <ul>  \n    <li>...a list of links here ...</li>  \n  </ul>   \n</div>  \n<div role=\"navigation\" aria-label=\"Secondary\">  \n  <ul>  \n   <li>...a list of links here ...</li>   \n  </ul>  \n</div>\n
\n
    \n
  1. Handling Headers
    2. \n
\n

========================

\n

It is very important for assistive technologies like screen readers to use headers the way it was intended to be used and not in any other (confusing) form.

\n

Main Heading

Sub Heading

Sub Sub Heading

\n

Anytime you are tempted to just bring in a h1 tag because of font, kindly head to the css file and style the sub header font instead.

\n
\n

Make text content readable and understandable and make Web pages appear and operate in predictable ways — Ire Aderinokun

\n
\n
    \n
  1. Handling Live Announcements
    2. \n
\n

===================================

\n

If your React application fetches any data from any external source like an API, it makes sense to put some kind of structure in place for people using assistive technologies to be aware of the fetching of data going on. We can achieve this with live announcements. Here is a sample live announcement component:

\n
import React from \"react\";  \n  \n  \nclass Announcements extends React.Component {  \n  render () {  \n    return (  \n        <div aria-live=\"polite\" aria-atomic=\"true\"   \n          className=\"visuallyhidden\">  \n          {this.props.message}  \n        </div>  \n    );  \n  }  \n};\nexport default Announcements;
\n\n

After the announcement component has been created, to use the live announcement we:

\n\n

this.state = { message: null; };

\n\n

this.setState({ message: “this is currently happening mate!\" });

\n\n \n

This would now set up live announcements properly for screen readers at specified points of your code where fetching of data occurs.

\n
    \n
  1. Using Fragments
    2. \n
\n

===================

\n

Fragments shipped with React 16.2.0, it allows you to group together a list of child elements without adding more nodes to the DOM. We know react component templates MUST always be wrapped with a HTML element for rendering to work correctly. This has made developers get really lazy and continuously wrap their code blocks with elements like divs (I used to always do this) We always end up with non-semantic HTML most times with the abuse of divs; remember how important semantic HTML is for accessibility.

\n

Take a look at this sample template from my react.lazy tutorial

\n
<div> {artists.map(artist =>(  <div>  \n    <li>1. Davido</li>  \n    <li>2. Burna Boy</li>  \n  </div>  <div id=\"card-body\" key={artist.id}>   <h1>MTV Base Headline Artists 2019</h1>  </div> )}<div/>
\n

The highlighted div actually really looks harmless but might result to non-semantic and sometimes invalid HTML and even creation of extra nodes like this when compiled back to HTML:

\n
<ul>  \n <div>  \n    <li>1. Davido</li>  \n    <li>2. Burna Boy</li>  \n  </div>   \n</ul>
\n

So using React Fragments is the right way to get around this problem I bet you must have had before. With fragments, we can now have the same template be like this:

\n
<React.Fragment>  \n    <li>1. Davido</li>  \n    <li>2. Burna Boy</li>  \n</React.Fragment>
\n

This results in really semantic HTML:

\n
<ul>  \n    <li>1. Davido</li>  \n    <li>2. Burna Boy</li>  \n</ul>
\n

For shortcut lovers like myself, there is an optional and simpler syntax for React fragments. It is the use of empty angle brackets:

\n
<>  \n    <li>1. Davido</li>  \n    <li>2. Burna Boy</li>  \n</>
\n

It is JSX syntax and it looks neater yes!

\n
    \n
  1. Keyboard Focus with refs
    2. \n
\n

============================

\n

We can use ref functions to handle where we want the user to focus on in our application. As your react application is a single page application with routes, it is important that users with disabilities know when a new route renders in the DOM because screen readers are silent when routes change. A more modern type of ref was introduced with React 16.3.0 React.createRef(). Using the new ref, we can control the focus with the following steps:

\n\n

A Few Helpful Tools..

\n\n

npm install eslint-plugin-jsx-a11y -— save-dev

\n\n
“plugin\": [   “jsx-a11y\" ]
\n

In the extends section:

\n
“extends\": [  “plugin: jsx-a11y/recommended\"]
\n

References

\n\n

Conclusion

\n

By going through this article, you must have picked up various steps that would not only improve your efficiency writing React, but would also make you a global citizen, one who thinks equality and does not discriminate while building for the web. Now go out there and become an accessibility advocate, happy coding! Feel free to comment and ask anything 👐

","excerpt":"Achieving Accessibility in React Applications a11y stands for \nThe phrase '11 characters'. Arrows are pointing to the first letter c and the…","fields":{"slug":"/web-accessibility-a11y-using-reactjs/"},"frontmatter":{"title":"learning accessibility standards reactjs","date":"June 04, 2022","tags":["web-design","reactjs","a11y"],"description":"learning accessibility standards reactjs"}}},"pageContext":{"slug":"/web-accessibility-a11y-using-reactjs/","previous":{"id":"b0c82b8d-3aef-589b-8093-ebf004823d6c","frontmatter":{"title":"learning svelte js quick starter","tags":["seveltejs","javascript"],"categories":["sveltejs","javascript"],"template":"post"},"fields":{"slug":"/learning-sveltejs-over-the-weekend/"}},"next":{"id":"a4e2a4aa-8ac2-5c5f-9448-4b80992b3788","frontmatter":{"title":"Build design system with reactjs","tags":["web-design","reactjs","a11y"],"categories":["a11y","reactjs","web-design"],"template":"post"},"fields":{"slug":"/build-design-system-with-reactjs/"}}}}, "staticQueryHashes": ["352937542"]}