3 ways for FEDs to lift your accessibility game.

The world of accessibility for a Junior Front End Developer can be a complex mass of unknown unknowns. In fact, the anxiety of not knowing where to start often results in people avoiding the issue completely.

But before we go any further, let’s get one thing straight. This article is not pleading the case of building accessibly. Plenty of authors have tackled this subject. There are many articles explaining the pro’s of an accessible approach and the short literature review is – just do it. Always.

In this piece, we’re assuming that you’ve mustered the energy and understand the reasoning. You’re simply lacking the direction. Do not fear, we’re here to help. And we’ll start with three lessons that we’ve picked up when making sites easier to use with partial vision.

1. Learn to use a screen reader

Could you imagine deploying code without seeing it ever rendered in a browser? You’d never expect it to be bug-free. You’d possibly, quite rightly, assume that it wouldn’t even work. Deploying new functionality or a new site without testing with a screen reader is analogous is essentially doing the exact same thing. It means you have no understanding of how a portion of users will experience your site. We recommend that, not only should you be testing with popular screen readers but, at the very least, you should be testing in the same way that users of this technology would decipher the content on a webpage. Doing this allows you to use assistive technology in a realistic way. Missing the stage would be the digital equivalent of you testing a cement mixer with cake batter. Insufficient, with results that are not informative (and certainly not tasty).

If you need to know where to start, there are an abundance of resources from Google courses to blog posts. All are designed to clearly demonstrate how people use screen readers. And they give clear instructions on how you can learn to use them. It’s important to start with a bit of scoping, because screen readers are, for users with partial vision, like browsers. Fundamentally they all do the same thing, in that they transcribe HTML content to audio, but just like Chrome vs Internet explorer, how they do that will always have slight differences.

So, what’s popular?

Well, here’s a list of some the most popular screen readers for desktop:

Data provided by: https://webaim.org/projects/screenreadersurvey8

It’s common for users to use native accessibility programs such as VoiceOver on Apple devices.

Now that we’ve identified some likely candidates, it’s time to dive in and learn how to use them. When it comes to native screen readers, you’ll find quite useful tutorials when you simply enable them.

Warning: this will be difficult… very difficult.

It’s going to completely change your understanding of the relationships between the different interact-able elements on your screen. If you’re like me, you’ll likely never have thought about how you might navigate through them if you had no idea how they were spatially related. All the buttons, tabs, address bars and plugins–and that’s just in your browser window.

Jumping through different application windows or navigating a site page is also wildly difficult. Even if you’re a power user who barely touches a mouse or trackpad, you’ll almost certainly rely heavily on visual inputs to get to where you’re going. Meaning there’s a level of patience you need to afford yourself when it comes to learning how to use screen readers.

Start with the goal of moving around a webpage (opening an application, or navigating to a new page will likely be too difficult to start).

The next step is learning how to use this technology in the same way that users with partial vision would. While there’s no substitute for sitting down with someone, getting a run through and asking a whole heap of questions, there are certainly plenty of videos out there that will help, from both developers and users.

The perfect example of this is that many users with partial vision will navigate a website by scrolling through all of the headings on a page, and then determine the likely location of the content they’re searching for after this. Knowing this certainly changed my perception of what semantically constitutes a heading in HTML as opposed to what is simply styled as such, and should not be using any heading tags.

Many other true insights are found when scrolling through the form controls on a page (links, buttons, inputs). These really highlight the importance of adequate text labels for the elements. Whether that’s adding text to buttons with icons, or making sure a form input has a label independent of its placeholder text, it’s important to follow this basic rule. All form controls need to be labelled with enough information that if they were all removed from their content and lined up in the order they appear on the page, there would be little ambiguity as to what they are, what they control, or what they contribute to.

2. Use lists and heading tags

The next key lesson is utilising HTML tags that are identified by screen readers to their fullest extent. While they’re not GPT-3, screen readers can pretty intelligently supply information based on markup to users.

You will have already noted, headings are the directory to your content on your page for users of screen readers. Which is why a lot of consideration should go into selecting the correct tag for a snippet of text on a page. Apart from general rules e.g. only having one <h1> tag per page, the following method is a great way to make sure your site is as accessible as possible.

Imagine your page is a grocery store, and headings are the items listed on the signs that appear above aisles.

Do you have too many kinds of items in one aisle? Do you have aisles without any signs at all? In the same way you generally expect shopping aisle to be similar lengths, it’s also reasonable to group a similar number of ideas within headings. Thinking about headings in this way will allow you to recognise when text should only be styled to look like a headings, and when it’s actually semantically a heading.

On to lists. Communicating relationships between all the information on a page often leverages visual space e.g headings followed by paragraph text indicates the two are linked, a heap of whitespace between multiple sections indicates a level of separation of the ideas or content. For screen readers, this information can be lost. An easy way to think about the information is essentially flattening a page into a single long line. Headings are like mile-markers on a road, lists offer a way to provide a few detours and can shorten the journey.

Any kind of information that’s singular in a group can constitute a list.

• A page with numerous sections of sequential and related content is probably a list.
• Is there an array of cards on landing page, each linking to details pages? That’s certainly a list.
• Navigation menus are lists.
• Clusters of buttons are probably lists.
• The social icons in your footer are also lists.

Using <ul> and <li> tags will alert a screen reader to the number of items in the list and allow a user to navigate through them, or skip the list entirely. It can clearly communicate nesting and slapping on an aria-label or role attribute will make navigating the content even easier.

3. W3 WAI-ARIA Authoring Practices.

W3C has put together a document that goes into great detail on the considerations for different components, behaviours and navigation when it comes to building accessibly. It is a treasure trove of knowledge. Following and implementing some of these examples will make you more acutely aware of all the pain-points screen reader users experience when they are attempting to peruse websites.

Up until now, when you’ve been building for sited users, completion criteria for a new component is something along the lines of: does it perform the correct behaviour, does it look like the design, and is it responsive?

After implementing some of these examples, you’ll be much more inclined to ask questions like:

• Does the user pressing key ‘x’ result in expected behaviour?
• Is the focus set to an intuitive location after this action completes?
• Are there parts of the screen that are inaccessible to sited users that key still be reached by keyboard navigation?

For example, a basic modal might not close on pressing escape, it may set the user’s focus to the first element, or could even make the rest of the page non-navigable. A modal built with accessibility in mind will. And using the W3 WAI-ARIA Authoring practices, you don’t have to do all of the discovery for yourself.

So go out, surf with a screen reader, code considerately and read-up so that you can stand on the shoulders of giants. There’s a lot of inherent satisfaction in creating something that can be enjoyed by everyone, and the testimonials from your clients – who rely on souls like yourself to create a more accessible web – will top up your tank and keep you pushing for more.