Building a Web for Everyone
Web accessibility often sounds straightforward - just make a website usable for everyone. But when you dig deeper, you will discover a rich tapestry that blends ethics, legal compliance, and technical challenges into one.
Let’s look at some different kinds of disabilities to understand better how they can change the way people use websites and why making sure everyone can access them is so important.
Web Accessibility Across Different Abilities
The spectrum of disabilities is broad, and it’s not feasible to discuss each one within the scope of this article. Nevertheless, it’s important to recognise some key examples to grasp how they impact an individual’s ability to use the web.
Disabilities can be either permanent or temporary and may influence a person’s visual, motor, auditory, or cognitive abilities. For instance, someone with a visual impairment might experience color blindness or macular degeneration, while a person with a mobility impairment may face challenges in using traditional input devices, and those with cognitive impairments may struggle with processing information.
Each type of impairment requires different accommodations from a website. For example, users with mobility impairments may need to navigate a page solely using a keyboard. In contrast, those with visual impairments might require text and images to have high contrast to ensure visibility. Meanwhile, individuals with cognitive impairments often benefit from predictable designs and easily understandable text.
It’s crucial to have an awareness of how various users might perceive and interact with your product. While the majority might default to using a mouse to navigate websites, others rely on alternatives like screen reader applications.
It’s also worth noting that anyone, at any time, can experience a temporary disability, such as a broken arm or misplaced glasses. In such instances, the way a person interacts with the web might be temporarily altered.
An Investment, Not an Expense
Incorporating accessibility into our products is essential for reaching a broader audience. The World Health Organization (WHO) estimates that about 15% of the global population lives with some form of disability. Ignoring accessibility (a11y) can mean overlooking a substantial portion of the market.
There are cases when making a website accessible is required by law. For example public organisations and some private businesses like banks and transports are required by The European Accessibility Act to make their websites user-friendly to everyone.
There’s a misconception that integrating accessibility into a product is an expensive endeavor that requires extra resources. However, the real cost comes from retrofitting accessibility into an already completed product. When the design is finalized and development is almost done, attempting to incorporate accessibility can be time-consuming and may require significant revisions, such as enhancing color contrasts that don’t meet standards or modifying navigation for keyboard-only users. Correcting accessibility late in the process often demands the attention of the entire project team once again.
Yet, this extra work and expense can be markedly reduced with a proactive approach to accessibility. By considering accessibility from the start of a project, ensuring that designs adhere to accessibility guidelines before development begins, costs can be contained. It means that developers can integrate accessibility features concurrently with other business requirements.
Accessibility can be likened to an elevator in a building, though it may increase initial construction costs and be costlier to install after a building is complete. Once in place, it not only benefits those who are unable to use stairs but also provides convenience for all occupants.
Building Accessibility into Your Workflow: Automated Tools and Best Practices
Once there’s a shared understanding of accessibility’s significance and we have attractive, well-crafted designs that align with best practices, it’s time to start building the actual product.
A straightforward first step for ensuring accessibility is to incorporate automated tools that will scan our code for potential accessibility concerns. I prefer using a combination of tools, specifically the ESLint plugin ESLint-plugin-jsx-a11y and the accessibility testing tool Axe Axe-core for React. These tools can help catch common accessibility issues early in development.
ESLint a11y plugin
Getting this linter up and running is a breeze. All you need to do is install the package and then incorporate it into your .eslintrc.cjs configuration file. Typically, I find that using the recommended settings is adequate. Should there be a need, you can easily customize it to suit your requirements by adjusting the severity levels of the error messages.
Once this plugin is activated, it assists in detecting accessibility issues at an early stage. You can observe its seamless integration with Visual Studio Code, where it delivers detailed error messages - for example, alerting you when an image tag is missing an alt attribute.
A screenshot of a sample linter error message
Axe by Deque
Installing and configuring the Axe tool is also easy. After installing it you need to enable it in the mainReact file. Make sure it is disabled in production mode.
Axe-core works only in Chrome and Firefox. To view the reports it produces, simply navigate to the developer console in your browser.
An example of axe-core warning message
This tool won’t just pinpoint the exact element within the DOM tree that’s causing the problem, but it will also show a link to Deque University. Over there, you can seek for a detailed explanation of the problem and potential solution.
Lighthouse
Lighthouse, which is famous for its web performance reports, also offers a feature to evaluate how accessible a webpage is.
Lighthouse accessibility score
CLI
Axe-core and Lighthouse audits can be executed via the command line interface too. Integrating these checks with a linter and incorporating them into your CI/CD pipeline lays a solid base to prevent the unintentional push of code that breaks accessibility guidelines.
Browser native a11y tools
Automated tools are helpful, but they only catch a fraction of the potential accessibility problems on your site. It’s essential to roll up our sleeves and double-check that everything meets accessibility standards.
While both Chrome and Firefox offer tools for accessibility testing, neither one outshines the other. I believe they enhance each other’s capabilities and should be used in tandem.
Accessibility Tree
Accessibility Tree is a structure similar to DOM. It provides semantics of the content - only the meaning, not how it looks like. Assistive devices and software, including screen readers, utilize this structure to explain to users what’s on a web page and how they can interact with it.
A screenshot of a website and it’s accessibility tree
When building websites it's important to ensure that our code is accurately translated into the accessibility tree. This is important because any content not represented in the Accessibility Tree may be hard to reach for individuals using assistive technology, making it difficult for them to fully access the site’s information and features.
Vision deficiency emulator
In both Firefox and Chrome browsers, there’s an amazing tool available that simulates different vision impairments. With this feature, we can understand how a website appears to people with color vision deficiencies like Deuteranopia, as well as those with blurry sight or low contrast vision.
A screenshot of simulated blurred vision
A screenshot of simulated reduced contrast
Naturally, this is just an approximation of how a person with such a vision impairment might perceive websites, so consider it as your initial checkpoint.
The Chrome element inspector showing contrast ratio
We can check the contrast ratio using the Chrome element inspector. And Chrome colour picker can even suggest what colours we can use to maintain the desired level of contrast ratio.
Tabbing Order
There’s another incredibly useful feature called the Tabbing Order in Firefox, which you can enable through the developer tools.
An example of tabbing order on a simple website
By activating this tool, you can see the sequence in which the focus moves when pressing the Tab key. Making sure this order makes sense is really important to ensure that users can interact with every clickable part of the website. Correct order improves the experience not only for people who can’t use a mouse but also for users who prefer using a keyboard for practical reasons.
Practical tips
I believe that particular attention should be given to navigation and forms when it comes to ensuring adequate accessibility. Both elements are vital as they frequently engage users—navigation being an often-used feature, and forms being essential for enabling users to perform various tasks on a website.
A form without labels
A form with invisible labels
The sign-up form presented appears sleek with its clean, minimalist design that avoids overloading with extraneous information. However, the use of placeholders as labels might pose issues for individuals utilizing screen readers.
Since placeholders disappear once an input field is filled in, this can create challenges for people with cognitive impairments to remember what information goes into each field. Furthermore, this practice can be problematic even for users without disabilities, as it might lead to confusion and fatigue, particularly when dealing with large and complex forms.
A form with appropriate labels
A much improved approach involves incorporating labels directly into the form. This enhances predictability and ensures the context is always accessible. Required fields are marked with an asterisk. Keep in mind that asterisks should be hidden from screen readers using aria-hidden property. And aria-required should be used to mark field as required for assistive technologies. Designs of this nature are beneficial for all users, regardless of their abilities. The cognitive effort required is significantly reduced when users can effortlessly verify field requirements while entering data.
Keep in mind that this is just a fraction of best practices in form creation. I recommend diving deeper into this subject to understand where to position validation messages and how they should adapt based on user interactions.
Semantic HTML elements
As web developers, we can make div look and act like buttons, even very sophisticated ones. But it doesn’t mean we should. Keeping our DOM semantically correct makes it easier to interact with for users that use assistive technologies. So it’s better to stick to the good old <button> and use tags like <main>, <footer> or <nav> .
QA & Feedback
Lastly, integrating accessibility checks into the quality assurance phase is a must. Manual testers should examine the page’s functionality and appearance when utilizing assistive technologies.
Finally, we should actively seek input from users who primarily interact with our products via assistive devices. Ensuring that they have a frictionless experience and encounter no obstacles or problematic areas is essential for true accessibility.
Summary
Web accessibility goes beyond the basic principle of making a website usable for all. It is a mixture of ethical responsibility, legal obligations, and technical challenges. Disabilities vary wildly in nature and impact, affecting different users’ ability to navigate and understand web content, each having different requirements from the web. A proactive approach to accessibility not only widens your audience but can save costs and enhance everyone’s experience.
Resources and further reading
W3Cx: Introduction to Web Accessibility | edX
Home | Web Accessibility Initiative (WAI) | W3C
Testing Web Accessibility by Adrián Bolonio
KATERYNA PORSHNIEVA - Practical guide to building accessible forms in React