Web Accessibility Overview

Published in

web-accessibility-overview

10 min readFeb 16, 2021

Recently I gave a presentation about accessibility in web to my colleagues and for some weeks a thought of turning it into a short article was swirling in my head. Eventually, I settled on the overview of the topic. In this piece I will discuss what accessibility means and why it matters. I will look into the main standard — WCAG (Web Content Accessibility Guidelines). Finally, I will touch on specific aspects of the standard and look into some examples on how to implement it and what the caveats there might be.

To start with, I will throw at you some statistics. Around 4.7 billion people at the end of 2020 were active internet users. Which roughly amounts to over 60% of the global population. Clearly — websites and apps have an impact on majority of humans on Earth. Around 1.5 billion people have some sort of disability and around 54% of them are active internet users. Color-blindness, e. g. affects close to 10% of the population. So, even without doing hardcore math — there is a high probability that part of users navigating your application or website will have some type of disability.

Usually, when we talk about accessibility, we reduce the affected to the people with impairments, most often — visual ones. Which in a way makes sense as this brings us to the history, the roots of web accessibility. The “movement” started in 1996 within World Wide Web Consortium (W3C) as an initiative group. This group was concerned precisely about the part of the population which had various disabilities and experienced difficulties using internet.

Disabilities themselves can be divided into various categories. I tend to place them under two groups. The first one — physical and sensory deprivations, such as hearing, vision or motoric difficulties. Which manifests in various levels of reduced hearing, vision, color blindness, shaky hands etc. The other group falls under mental & intellectual difficulties. This one is really broad, starting with dyslexia, dyscalculia and going up to ADHD or age-related conditions. However, this group covers just one type of disabilities — permanent. It may seem insensitive to put the following two groups under the umbrella term disability, but in reality temporary and situational disabilities make the users very limited in the way they interact with the website or an app. Anything from broken limbs, ear infections to the new-born baby in the house or over-tiredness come into the latter two groups. If a dog owner is reading this article, you would recognize the situation of trying to buy a public transport ticket while walking to the stop with the dog on a leash. At that moment you are nothing but grateful for a user-friendly, clear, readable and fast interfaces. These two groups make the previously mentioned number (1.5 billion) of people with disabilities highly fluctuate and be much bigger than that.

It looks like we are gathering a crowd!

Once we start thinking about the groups which are affected it is easy to realize that accessibility is a broader topic than improvements for color blind or deaf. I would like to point out two very important groups within the realm of accessibility: the so called ‘power users’ and mobile users.

To put it simply, the power user group consists of people who’s primary tool is the keyboard. Usually, this is a choice not a necessity. Nevertheless, for these users it is crucial to able to navigate the app/website via keyboard only. Not to mention a well-known secret that users love to work with familiar patterns. Especially, within the apps which we use day after day. Here shortcuts come in really handy. Regarding them, one rule is essential: not to override the long-standing combinations, such as ctrl + F.

Thinking about power users, another gotcha is that we may run into the so called “blinking twelve problem”. This term is used to refer to the features in software which are unusable to most users because of the complexity of the interface. The origin is the “clock” feature of many VCRs, manufactured in the late 1980s. The clock could be set by using a combination of buttons in a specific sequence. Since it was too complicated for most users, VCR would usually just blink with the default time — 12:00.

Last but not the least — the mobile user group. This may sound off topic but the essential reason to place them here is the overlap of many accessibility issues with those experienced by users with disabilities. Creating projects with accessibility in mind will also reduce the number of issues that mobile users may have. Taking into account the growing dominance of mobile devices in our lives, such a “bonus” is indeed tempting.

Considering the above, it is clear that accessibility makes lives of many people easier. Yet if you need more convincing, think about the legal requirements — different countries have different rules and certain level of compliance with accessibility requirements may be mandatory (e.g. Norway, Canada, USA). Clients as well might specifically request to comply with a certain standard. Besides this, it helps with SEO optimization: accessible websites mean more conversions, a lower bounce rate, fewer complaints. All of these stats are key for search engine ranking.

Now let us go back to the roots of web accessibility. 1996, W3C. The final product of the initiative was, what today is known as, WCAG (Web Content Accessibility Guidelines). It is a technical standard on how to achieve accessibility. At this point in time there have been two revisions and in 2021 the third one is about to come. It is a lengthy document and honestly — I would not recommend just trying to read through it. Certain chapters remind more of a legal text or the beginning of the Book of Genesis. From my experience, amore reasonable approach is to pick the problem which you are dealing with at the given time and target it specifically. Though in defense of the standard, it is written in an understandable manner, in the beginning there is a segment about what has changed in comparison to the previous version.

The standard is organized into guidelines which follow four principles: perceivable, operable, understandable and robust. The core of perceivable is to provide alternatives (audio to text, non-textual as text), guarantee readability and the possibility to distinguish between elements (guidelines for contrast, text resizing, spacing etc. are laid out in detail). Operable means that the project has to be available to be used with keyboard only. There must be no keyboard trap, the user has to be provided with enough time to use the product (consider session time-outs), anti-seizure provoking rules are described (e.g. no more than three flashes per second), the mechanism to turn off animation/auto play has to be in the forefront and many more. Understandable — in my opinion, this one is very close to the first one. In a way it moves closer towards the content: requires correct grammar usage, predictability of the text and the flow of the app, detailed guidelines about input assistance (e.g. error messages, labels, suggestions, help pages) are provided as well. Finally, robust translates to the possibility for a variety of user agents (assistive technologies, such as screen readers) to use the product. This principle can be implemented by providing complete start and end tags, ensuring correct nesting, making sure that there are no duplicate attributes, names and roles are assigned correctly and status messages (e.g. feedback about performed actions) are provided to the user .

I will not go into more details about the guidelines, yet what I find necessary to highlight is that there is a noticeable shift towards introducing rules relating to mobile experience. In addition to this, some security related matters (e.g. cognitive tests to authenticate the user) get touched upon as well.

In the real life what we usually hear are the letters A, AA (double ‘a’), AAA (triple ‘a’). Where are they coming from? One can find them in the same guidelines, under the section about conformance strategy. This subject is at the core of accessibility. Conformance consists of five parts which basically are the foundation for all the rules in the guidelines. A levels are the most detailed and practical part of it. Hence, more often than not, A levels are equated to accessibility itself. 2nd and 3rd parts of conformance mean that the project cannot be partially compliant — the whole page or the whole process have to conform to one of the A levels. 4th part means that it is possible for the assistive technologies to successfully present the content’s information to the user. Lastly, the 5th is a bit more complicated but in essence it boils down to this: a part of the content can be inaccessible if it is also presented in an accessible way and it does not interfere with the user.

So, the goal of any application is to match a level of conformance. Level A is the basis of the standard. I like to view it as something comparable to opening and closing of parenthesis in your code. It is a must — overwise, the product is basically non-functional. On the opposite side we have the level AAA. Which is the ideal. This one I consider to be something like a 100% tested code with 0 comments because it is flawlessly self-explanatory. In other words — hardly realistic to be complied with 100%.

Luckily, in the majority of cases level AA is the standard which is to be followed. Here it becomes either very clear or very confusing. If you want to stick to the clear — just follow AA. In web it is perceived as the gold standard and the recommended level to follow. But if you want to go for the confusing path (or you are in the role where you have to be concerned about this more than is reasonable) — then the legal requirements kick in. They can come from national, sector regulations or from specific contracts. My personal guideline would be to strive for AA without asking, just introducing it to your daily coding practice and if the project requires a higher standard that should be made clear within the team and laid out in the requirements.

OK, we know that we need to do it. How do we do it? Here comes the tools and testing strategies. We can use what I like to call retroactive and proactive strategies. Most of the tools that we are familiar with use the first one. Meaning — they will point out the mistakes or potential dangers of already implemented code. Chrome has a Lighthouse tab which has an integrated accessibility check. The generated report is quite detailed and I personally use it most often. Firefox browser has an accessibility tab, recently they introduced a beta feature which shows tab order of your website. This one is handy if you are working with keyboard navigation issues. Numerous browser extensions — WAVE, Axe, Funkify — are very visual and show the errors/warnings directly on the component.

Yet if you are in a position where you are starting the project from scratch, go for the proactive set of tools. Which means — use the assistive technology devices while writing the code. Most often this will be a screen reader. NVDA comes for free for Windows devices, Chrome has an extension “ChromeVox”. JAWS offers a free trial and Mac OS comes with a built in screen reader. Quickly you will notice that there are differences between the readers themselves. Yet the main issues get exposed rather soon by all of them. On top of that — do not deviate from the HTML standards and give a generous thought about your layouts before building them. Most of the times it will be painful and slow to start but eventually you will get the hang of it and be thankful once the retroactive set of tools will show just a few or even no errors.

Overall, there are two sets of requirements which we need to think about while creating an accessible project. I call them design and functional compliance. Design compliance is very important but if you work in a company you might not have it in your control. E.g. when the designs come from the client’s side/agency, separate design department. This situation may lead to a big conflict as a project can be AA/AAA compliant only if all parts are compliant. This is more of a business-analyst/legal department question what should be written in the contracts. Still, the developers can and should always consult and point out the issues. Yet if you are working on your own and are creating the designs yourself — make sure that the contrast, spacings, required target sizes etc. are maintained throughout all of the designs.

For developers most important is what I would call a functional compliance. This can be split into more static and dynamic parts. The first one concerns semantics — correct usage of HTML. A classic example here is to use headings in sequential order. This is how a user might form a mental map of your page so skipping a heading is not an option. Various semantic tags, e.g. <nav>, <footer>, <main>, <scop>, <region> come in play here too as they help people to get the clear picture about the app structure.

The second part relates to UI controls. When you work with a framework (e.g. Vuetify, Bootstrap), it is easy to forget that even the simplest components cover a lot of interactions and changes. If, let’s say for design purposes, you have to create a button or checkbox from scratch, soon it becomes clear that it is going to be quite a lot of work. Here a classic example would be a <div > styled to look like a button. Even if it has all necessary visual cues, the functionality will not be there and it will not be picked up by the assistive technology. A screen reader would announce such component as “sign up, group” because generic elements, such as divs, are intended for grouping elements.

On top of that, some components will have a higher complexity. Various elements can fall here, e. g. heavily animated examples, art works, forms consisting of multiple steps, charts with a lot of data points etc. Personally, I have experienced some challenges with “Highcharts “ charting library. Luckily enough, this charting framework offers accessibility module. What I was able to do is to add “accessibility” object into my chart configuration and provide additional textual information which made the chart more comprehensible. The point being — do not forget to look for solutions within the tools that you are using.

Now, where all this leads is to what is known as Web Accessibility Initiative — Accessible Rich Internet Applications. This methodology was created to help with the aforementioned issues. Aria, as it is known for short, helps in making non-accessible components accessible. How? Using roles, properties and states. What you have to do is to specify these attributes on elements and they then modify the way those elements are translated into the accessibility tree. To put it shortly — aria modifies the accessibility tree. However, it does not impact any other aspect of the elements. What it means — the appearance, behavior or focus won’t change. Most importantly — JavaScript will be needed to handle the events and change of states. For example, enter or spacebar press will have to be captured and functions executed on those events.

For the end, I would like to share a list of my most used web accessibility resources:

Web Accessibility Overview

Written by Justina Dešriūtė