Blog 26.5.2023

What should every frontend developer know about accessibility?

Competence

Goforean sitting on a windowsill with a laptop on their lap.

Just like taking care of proper error handling, security or efficiency, accessibility is a part of making quality first-class software. You should embrace different user groups, different modalities, and devices to use your web page or web app. What if the user wants to listen, not read the page? What if the user doesn’t use a mouse? Things to look out for accessibility are on the same level as catering for users with small screens or slow connection. 

Key points to consider with accessibility

Accessibility is taking different usage scenarios into account. When developing accessible user interfaces, here’s key points to consider:

Structure and semantic elements

Structure should be able to be skimmed as well as heard. If you just have divs on your web page, for screen reader it is just a wall of text. Whenever you are going to write a div, ask yourself: What is this div for? Is it main navigation? Is it for grouping elements that belong together? Is it main heading of the page? Or is it just container of some text for visual layout?

It is important to use H1, H2, main, nav and footer elements, for example. It gives the rhythm for the page and emphasizes the right things. With a screen reader, it is possible to list just headings and jump directly to a certain point of a page, so the user is not forced to listen to the whole text. 

Heading levels

We have seen many times that heading levels are skipped. The basic rule is, that there’s only one H1 per page and next heading is level H2. Subheadings under H2 are H3, H4, H5 and H6 in order. If the size of the heading is too big, use CSS.

Links and buttons

If taken out of context, would you know where a link takes, just by reading the underlined text? For example, if there are several links named “edit”, you can make them accessible by using aria-labelledby attribute.

For clickable elements, use links and buttons, not divs or spans with onClick attached. Remember that onClick is mouse event, it does not translate to keyboard events unless used with native elements like button or link (a with a href attribute). 

Images

If the image you have chosen was left out, would the page still be understandable and convey the same information? There are many types of images: logos, icons, graphs, diagrams… Think about describing your page to a friend over a phone. Would you just skip images, or say something about them? This guides you to decide, whether you need alt text or not. 

Reading order for a screen reader

Remember that the reading order for a screen reader is the DOM tree order. You can use your browser’s developer tools to get an idea how the page sounds like for a screen reader user. It is also a good practice to tab through all links and form fields to check if the order makes sense. For example, if there are first name and last name fields presented visually in separate columns, they should follow each other when tabbed. Prefer DOM order with CSS (for example flexbox layout) instead of playing with tab index.

Valid HTML is a must

If you do nothing else, remember at least this: Writing valid HTML is the first step towards accessibility. If you are strict on this, congratulations! You are already on a good path towards accessibility.

Browsers, as well as screen readers, are built on standards. Breaking standards will cause unexpected situations. It depends on the error handling of each software how the invalid HTML is presented. For example, if you forget a closing bracket or a quotation mark, it might show just ok on the browser, but screen reader might start reading the code.

Modern web applications often have their inner state handling. It is possible to create radio buttons without defining a group name. Selecting radio buttons by mouse works, value is passed correctly, everything seems fine, but tabbing order and making selections by keyboard might be broken. You can catch these flaws with keyboard testing. 

The point is: In many cases, one size fits for all. At least, it is a good start! If the web page or web app has more advanced features, there might be a need for some more advanced accessibility code. 

I wish you an easy start towards web accessibility!

References and recommendations:

Harvard University: Write good Alt Text to describe images

MDN: Radio button examples

React: Semantic HTML

W3C: Validate your code

Read also: What every designer needs to know about accessibility?

accessibility

Leena Konsala

Senior Software Developer

Leena is a software developer who has long experience in developing web applications, both frontend and backend. She has also designed speech user interfaces. Currently she is working with design system in public sector project. Leena is interested in modern web technologies, user experience and usability, beautiful design and accessibility, as well as agile methodologies.

Back to top