From Concept to Code: Ensuring Web Accessibility Every Step of the Way

Welcome back to our blog series, "THINK BIG AND GO ACCESSIBLE!".

We began this series with a post that introduced the topics we'll discuss. If you’d like to revisit it, we’ve left a link for you here.

In a nutshell, we discussed how important accessibility is for all users AND for the growth of your business. WIN-WIN SITUATION! Your website becomes accessible to everyone on the web, regardless of any limitations they might have. At the same time, you can reach more people and do better in business.

Sounds good, right? If you're interested in what implementing accessibility looks like behind the scenes, this post is for you. We will guide you through the entire process — starting with design and ending with maintenance. 

Now, let's get down to business.

Design

As with everything, it is necessary to set a game plan. Why? Because to be effective, accessibility should be included from the outset and throughout the early phases of the project.

A website's ease of use mostly depends on its design. If you think about accessibility from the start, its implementation becomes easier and more enjoyable. It's essential to match your website idea with what the UX/UI designer suggests. If the website design is good, it's easy to make it accessible.

But what if the UX/UI designer's vision of an accessible website does not meet your expectations? Then, you need to consider the pros and cons of implementing accessibility, see some alternatives, suggest other options, and importantly, take into account the target audience and business requirements. You might have to meet in the middle.

For example, if you want to use certain colors that don't have the suggested contrast, you could add dynamic style changes. The site could automatically switch to a style with higher contrast when it detects a user with a screen reader. So, it allows the site to adjust to each user's needs.

Introduction to accessibility

WCAG has different levels of accessibility. Each level has its own requirements. The decision on which level to target will depend on both industry standards and country-specific legislation.

Levels of accessibility

Level A

The basic level of accessibility covers only the most critical aspects of accessibility. It is very easy to achieve, but may not be sufficient for the wider public. 

Level AA

A higher level that meets the needs of a significant number of users. It is a commonly chosen solution. The AA level represents a robust accessibility standard. Making a website legally accessible usually means achieving these WCAG AA standards.

Level AAA

The highest level of accessibility. It is considered to be accessible for all users, including those with the most significant accessibility needs.

Accessibility levels in action

Let's use an example to make the differences between the levels clearer. Imagine your website has a contact form.

A: For Level A, the requirement would be that the fields of this form have labels — each field must have its own name.

Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

AA: For Level AA, the requirement would be that the form fields have names that clearly indicate the purpose of each field.

Success Criterion 1.3.5 Identify Input Purpose (Level AA) The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning of form input data. 

AAA: For Level AAA, the requirement would be that the entire form must be accessible via the keyboard, and no time limit should be imposed on pressing keys to perform a function.

Success Criterion 2.1.3 Keyboard (No Exception) (Level AAA) All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. 

So, where were we? Did you give the thumbs up to the design? Yes?! Then it's time to get the ball rolling!!!

Development

The second step is making it happen. This step is about bringing our plans to life. For those who aren't tech-savvy, hang in there!

During development, sticking to software development best practices is crucial. Why? 

This is because we care about making the website easy for everyone to use. The basis of this is a well-built website, whatever technology the developers use.

Some tools can help developers make the website accessible, like the React Aria library. There are also plugins and extensions, like the ESLint extension eslint-plugin-jsx-a11y, which checks the code for accessibility as it is written. 

Speaking of the devil, developers also sometimes face smaller or bigger problems. You might be surprised by what challenges they may face. We have described the three most common ones below.

Accessibility elements introduced during development

Custom keyboard navigation

By default, the browser handles keyboard navigation for elements like buttons, and inputs.

Sometimes it’s not enough and we have to implement our custom navigation for such

cases like using arrows or navigation closed in the single element like a modal. It demands more complicated JS scripts, so much larger effort. 

Of course, we must follow the standards, and there are some basic shortcuts that should work over all our pages:

• TAB — move to the next element
• SHIFT + TAB — move to the previous element
• ESC — close element (dropdown, tooltip, modal)
• ENTER/SPACE — interact with the element (like a mouse click)

These keys should always work the same and you should never change their purpose!

If you have problems implementing valid navigation, especially with complicated elements, consider some well-known library that handles it for you and significantly speeds up this process! You can use Material UI, Bootstrap, Ant Design, and much more. They do great work and have a large community. 

ARIA

ARIA attributes and roles help screen readers explain to users what they can do with current elements. It's especially helpful for users with low vision. Browsers can not always handle it for us (what a shame!). By using these attributes, we have to explain to the user, what the current element is, what content it presents, or can we click that. Almost everything has to be handled by a programmer.

ARIA role — it defines what my current element is. For example, radio input has the role of “radio” and then the screen reader knows exactly what the user can do with this element. But, unfortunately, the world isn’t such an easy place. Dialogs, sliders, menu, menu items aren’t properly read by the screen readers. This is why we use a role attribute - thanks to that the screen reader can more precisely describe which element users can interact with. 

ARIA attribute — while the role describes what the element is, the aria attribute describes what is inside this element and what state it has. We can add an accessible label to element (aria-label), inform the user whether we can open this element (aria-haspopup) or check if it is turned off (aria-disabled).

There are documentations like W3C ARIA or Mozilla ARIA which help developers to properly code specific UI elements. We can find acceptance criteria with real examples. These standards were made by experts so better follow them.

Contrast

During our website development, we have to take into account proper contrast between our colors. Design can be beautiful, but if it doesn’t take it into consideration, our accessibility score will be decreased. Before development, it’s required to find a compromise between designer ideas and valid contrasts.

Development tools for ensuring accessibility

There is one indispensable question for programmers after they finish coding. If I was disabled, would I be happy with interacting with my site? While implementing an accessible page, our first goal is to help such users and make the world a little bit happier place. 

To save the developers time and effort, it is recommended to use some tools and plugins. For example, by integrating plugins like ESLint, SonarLint, and WebHint into the development workflow, it is possible to create a robust system for catching and addressing accessibility issues early and often. 

Eslint-plugin-jsx-a11y

Accessibility focus: 

• ESLint can be extended with plugins like eslint-plugin-jsx-a11y, which includes rules specific to accessibility in JSX (used with React).

Example rules:

• Ensuring keyboard accessibility for all interactive elements.
• Correct use of ARIA roles and properties.
• Checking for appropriate alt text on images.

SonarLint 

Accessibility focus:

• Helps prevent accessibility issues like poorly structured HTML and inefficient JavaScript.
• Fixing vulnerabilities contributes to a more robust and accessible site, as insecure code can indirectly affect accessibility.

WebHint 

Accessibility focus:

• Checks for issues like missing alt attributes, improper ARIA roles, and accessible interactive elements.
• Offers suggestions for fixing accessibility issues, aiding developers in understanding and resolving them.

Prefers-reduced-motion

Accessibility focus:

• If this option is enabled in the browser, the page should have reduced animations because of user request
• Helps users with vestibular disorders, when too many elements on the page move or change their colors

Example usage:

".animation {"

"  animation: pulse 1s linear infinite both;"

"}"

"@media (prefers-reduced-motion) {"

"  .animation {"

"    animation: none;"

"  }"

"}"

Testing

Building the website and testing it go hand in hand.

Testing should happen along with the development to make sure the website works well and is of high quality. Tests should be manual and automated. Automated tests quickly catch common mistakes, such as missing or invalid properties. Manual tests help find accessibility issues that might have been missed. So, it's best to do both kinds of tests.

To perform accessibility tests, you can activate a screen reader such as VoiceOver for macOS or NVDA for Windows. You can also adjust the size of the text to ensure readability, check that items do not auto-play or flash, and navigate the page using only the keyboard.

But don't forget about the tools, they can reveal possible errors more efficiently. Here are some of our favorites:

ANDI

ANDI is an easy-to-use tool that helps with manual testing. It doesn't need to be installed and runs from a bookmark. The tool checks many things that are important for website accessibility. ANDI has different modules for different parts of accessibility, including

• The "focusable elements" module, which focuses on interactive elements and tab order.
• The "tables" module, which assesses data tables and cell associations.
• The "graphics/images" module, which examines alternative text.

ANDI also has modules for links/buttons, structures, color contrast, hidden content, tables, and iframes.

When ANDI checks a page, it shows how many elements it found and if there are any problems. Highlighted elements make it easy to identify on the page. If an error is detected, the tool provides helpful tips and suggestions for fixing it.

Using ANDI to label all parts of a website can make it easier for people to use assistive technologies. It's a powerful tool with many options, so it's good to get to know it.

Color Contrast Analyzer

Color Contrast Analyzer is a tool for checking the color contrast between text and background. This tool helps meet the color contrast rules from standards like the Web Content Accessibility Guidelines (WCAG).

Measure Contrast: It measures the contrast ratio between any two colors on a website. All you need to do is select the foreground color and the background color.

Check Compliance: It checks if the contrast ratio meets WCAG standards at two levels (AA and AAA) including regular and large text.

Show Contrast Issues: It shows where the contrast isn't enough on a web page and helps understand which parts need to be improved.

Axe Devtools

Axe Devtools supports both manual and automated testing because it can be used as a browser extension or it can be integrated with Playwright or Cypress.

Axe Devtools uses many accessibility rules based on the Web Content Accessibility Guidelines (WCAG), for example:

1. The button has a non-empty accessible name: Each button needs to have a name to inform users what this button can do. It’s important for people who use screen readers.
2. The text has minimum contrast: The text needs to be easy to read against its background. It’s important for people who have low vision.
3. HTML page lang attribute has a valid language tag: Web pages need to say what language they're in. This helps screen readers and other tools read the content in the right language.

Explore all accessibility rules implemented by Axe Devtools.

Axe Devtools is easy to use for manual testing, by scanning the whole page (or just a part of it). The tool gives you a detailed report, you can highlight the failing element or inspect it to exactly know where the issues are. Additionally, it will give you hints on how to fix them.

For automated testing, Axe Devtools can be integrated with Playwright or Cypress, allowing you to include accessibility checks in your automated test suites.

Maintenance

We did it! Your state-of-the-art website is done! Enjoy your new, better website, and grow your business! 

While you're busy with expansion, we'll take care of your website maintenance. In this fast-paced world, never forget the importance of site upkeep. A key strategy is automated testing. Using automated tests helps to keep and improve the website's accessibility over time. It's an efficient way to make sure everyone can use your platform. 

I think it's time to announce our biggest player, Playwright.

Long story short about the Playwright. It is a powerful tool for end-to-end testing, but let's focus on features for accessibility. Playwright can detect problems such as:

• The poor color contrast, which can make reading hard for people with low vision.
• User interface controls and forms that don't have useful labels for screen readers. This makes navigation difficult for people who can't see well.

The tool can be used in many different ways. You can use Snapshots to deal with common problems or choose to run manual scripts. Playwright can easily work with Axe because of the @axe-core/playwright package. Axe is known for checking many accessibility rules automatically. Some of these rules follow the Web Content Accessibility Guidelines (WCAG), and others are seen as "best practices". If you want to focus on certain rules, you can use the AxeBuilder.withTags() function.

When a rule comes from the WCAG, there's a tag for the success criterion number, like wcag111. If you want to look at other tags, check the documentation here.

Playwright is a complete tool that lets you check specific parts of a page, fix known problems, and set up tests for regular accessibility checks across different tests. It's the only tool you need for all your automated web testing.

Budget

Alright, now you might be thinking, “Hold your horses, how expensive is this going to be?!…”.

I bet you won't be surprised if I say 'It depends.' BUT! It truly depends on the company you choose to create your website with. 

We see accessibility as a BASIC NEED, just like fast loading speed or SEO. It is not just a bonus marketing feature! It is not just icing on the cake. Accessibility is a core rule we follow because we're making websites FOR ALL! So, we do not need an extra payment to make the internet a better place.

From design to launch

We know the process and we understand how to implement features correctly from the very beginning.

I hope you now realize how important it is to think about making websites accessible right from the start. From proper design that includes WCAG standards and collaboration with UX/UI designers, through technical implementation aspects such as keyboard navigation, ARIA, and color contrasts, to manual and automated testing, and finally maintenance.

Let's say it out loud — accessibility should be the standard for all those responsible for the web development process.