Quick Guide: Accessible Web Applications – Digital Accessibility Malta

How do you ensure your web application is accessible?

Whether planning a new project or revisiting an existing one, there are a few techniques you can adopt to ensure your site is accessible for a variety of users. By definition, and based on guidelines that are applied almost universally (WCAG), an accessible web application needs to be perceivable, operable, understandable, and robust. This means that all of the information and user interface components must be visible to users in some way or another and that all users are able to achieve their goals. Furthermore, the content and interface itself should not be confusing and must also be authored in a way that is interpreted and rendered reliably across different browsers as well as assistive technologies (ATs). This may sound overwhelming, however if you follow these few simple steps, you and your team will start developing an accessibility-first mindset and in turn, accessible and usable web applications. In case things start getting out of hand and you need more assistance, feel free to reach out by clicking on this link.

Let’s get started!

But how do you go about building technology that is accessible for all? How do you make sure all assistive technologies are catered for? The answer is simple – you don’t really need to worry about that. If your code follows standard specifications and is semantically correct, user agents (browsers and assistive technologies) will know how to handle the rest! Issues will come up if you deviate from specifications on which user agents are built – more on this soon.

You have a great opportunity to introduce an accessibility-first mindset, which translates into the following 4-step pattern as part of your technology delivery process:

Embrace the platform, don’t fight it
Adopt patterns and frameworks
Test features, journeys and improve your pipeline
Involve target users and get audited

Steps 1 and 2 apply across projects irrespective of size, however, steps 3 and 4 highly depend on the nature of your project. Some teams might opt to test every new feature, others might prefer to test entire journeys, while others leave this till the very end – which is of course not advisable.

So, let’s dig slightly deeper.

Step 1: Embrace the platform, don’t fight it

The platform is trying to give you accessibility for free.
Rob Dodson (Chrome Developer Advocate)

This is a very simple idea: developers need to understand and think about the platform they’re developing for. Make sure you or someone on the team is well versed with standard specifications. Browsers are built to process scripts (HTML, CSS, JS) and render content according to standard specifications. In particular, developers should have intimate knowledge of the HTML standard, since this reflects the content’s structure and meaning. If you build according to standard specifications, browsers and assistive technologies will do the rest.

If you build according to standard specifications, browsers and assistive technologies will do the rest.

While parsing markup, browsers generally build two models – the document tree and the accessibility tree. Both are important aspects of the accessibility-first mindset, and developers need to be aware of these.

The document tree is an internal representation of all elements on a page represented as objects and their attributes. This tree is necessary for user interaction, both manual and programmatic (via the Document Object Model). Some users make use of a keyboard to interact with your web page by tabbing over elements in a sequential manner, and therefore the order of the elements on the document tree dictates how efficient or logical keyboard access actually is. Sometimes, elements on the document tree are not aligned with their visual representation on screen, possibly due to the use of some arcane CSS rules (hacks) to change visual order – and this will have a negative effect on users opting to traverse the page using a keyboard.

The accessibility tree represents accessibility-related information for all elements on the page (based on the document tree). This is in turn consumed by assistive technologies such as screen readers. For each element on the page, the accessibility tree includes details about the element’s role, description, current state, possible states, whether the current element controls any other element, and so forth. This data is necessary for non-visual users to perceive and operate, where applicable, page elements correctly. The Accessibility Object Model (AOM) is a JavaScript API that allows developers to access and modify the accessibility tree – however, this is mainly aimed at a subset of developers who focus on developing JavaScript frameworks and component libraries.

Deviating from standard specifications (i.e. HTML) means that browsers will not be able to build correct page representations for assistive technologies. For instance, if a developer uses a <span> instead of a <button>, even it is made to look and behave like one, ATs would still not be able to announce the component correctly and in turn users would not understand that it is a button and that they can operate it by pressing enter or by tapping on the screen. Therefore, in principle, developers need to understand the meaning of semantically correct markup.

Sometimes, you might be building something for which there is no corresponding “native” HTML element or which might be heavily reliant on Ajax calls (e.g. dynamic tree-menu). There are two options here:

Avoid the temptation and find simpler alternatives (recommended).
Adopt ARIA attributes to help the browser construct meaningful accessibility trees.

The Web Accessibility Initiative’s WAI-ARIA (Accessible Rich Internet Applications) is a W3C technical specification and set of guidelines that “defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies” (source: https://www.w3.org/WAI/standards-guidelines/aria/). WAI-ARIA provides a set of attributes that can be used to supplement your markup and in turn help browsers interpret elements correctly (for accessibility purposes), before passing them on to assistive technologies. W3C discourages the use of ARIA attributes whenever a native HTML element can be used (see the first rule of ARIA use).

Pro-tip: please be aware that implementations of accessibility APIs may vary across operating systems, OS versions, browsers, and browser versions. Therefore, rigorous testing is also very important.

Where can you get training?

Here is a list of (mostly) free courses that you or your team can embark on:

Introduction to web accessibility by W3C on edX: Introduction to Web Accessibility
Accessibility fundamentals by Microsoft: Accessibility fundamentals – Training | Microsoft Learn
A free course on web accessibility by Google on Udacity: Developing with Empathy
Pluralsight offer a good course path about accessibility (no commission is received from this referral): Developing Websites for Accessibility
Google has a great free tutorial: Web Fundamentals – Accessibility
Free digital accessibility training for managers, testers, developers, and designers (Erasmus+ EU funded project): Certified Digital Accessibility Training

Need more assistance on this matter? Feel free to reach out by clicking on this link.

Step 2: Adopt patterns and frameworks

WCAG offers a quick reference that allows you to understand how to approach any aspect of your development exercise. For instance, if you are not sure how to develop an accessible form, then this reference will provide you with all the information you require to build and test that component. If you need to develop custom components for a rich web application, you can also look at the Web Accessibility Initiative’s ARIA Authoring Practices Guide (APG) covering aspects such as design patterns, expected keyboard behaviour, use of landmarks, and so forth. These guidelines also come with code examples for different components as well as recommendations on the proper use of ARIA attributes.

Pro-tip: It is recommended to build a company-wide library of re-usable components so that lessons learned from one project could be re-used in future projects (consider a private Git repository, or better still a public one).

There are other pattern/component libraries you can use, such as:

However, an accessible web application is more than just a collection of accessible components. Aspects such as efficient keyboard navigation, logical organisation of information, focus visibility, consistent navigation across pages, content block bypass mechanisms, sufficient colour contrast, and predictable behaviour must still be taken care of independently of components used.

…an accessible web application is more than just a collection of accessible components

Having said that, many UI frameworks ship with embedded best practices that have evolved over a number of iterations. By using a framework, your team will build on top of tried and tested practices and techniques that will further align your applications with WCAG guidelines and associated success criteria. Of course, this all depends on the correct use of such frameworks.

Some frameworks come with built-in accessibility best-practices, such as the following:

Sometimes, you might need to incorporate a component library (extending your UI Framework). Once again, make sure you select libraries that respect accessibility recommendations and are ideally aligned with WCAG 2.1 guidelines. Most reputable component vendors issue a compliance statement.

Step 3: Test features, journeys and improve your pipeline

After completing a feature or user journey, test your work. It is recommended that you test incrementally, rather than everything at one go. Consider adopting at least one of the following approaches:

Manual testing

Try to use the feature or complete the entire journey using the keyboard only. Try to navigate and complete actions using the tab key along with the spacebar (e.g. to expand drop-downs), arrow keys (e.g. to select items), escape (e.g. to close a drop-down) as well as enter (e.g. to make selections). Can you access all the elements on the page? Do you know which element you’re currently focusing on? Make sure that you always get a clear focus indication, and that this is not disabled via some styling rule. Also, look out for keyboard traps. Can the user navigate away from all elements using only the tab key (or shift-tab to go back)? Do you have to repeatedly tab over a number of items before reaching the main content once a page loads (e.g. mega-menu at the top)? Make sure you offer ways to bypass blocks of repeated content. Also, is the focus order logical when tabbing over elements on the page? For instance, given a form, can the user move sequentially from one field to another? You should not override the tabindex attribute yourself – if the element’s order on the DOM matches the visual order, then the user agent will ensure a logical focus order. Also, make sure that the UI is predictable, and that page updates only happen when a user confirms an action (rather than automatically).
Try to navigate the feature or entire journey with the monitor switched off using only your keyboard along with an open-source screen reader such as NVDA. Is the screen reader giving you enough information to understand the purpose of the page? Ensure you have a unique title tag as well as a meaningful level 1 heading on each page. Are input elements announced in a meaningful way? Make sure controls are labelled properly. Is the screen reader producing too much audio clutter? Make sure that decorative images are actually hidden from screen readers, by using an empty alt tag. Can you complete the intended task? Also make sure that where applicable, images have a descriptive alt tag.
Is your site also meant to be accessed via mobile devices? If so, navigate the feature or journey using VoiceOver (on iOS) or TalkBack (on Android). VoiceOver and TalkBack are assistive technologies that ship by default with the respective mobile operating systems, and are designed to help blind and visually impaired users access native apps and web content (TalkBack might not be available by default on development emulators however you can get access to it by installing Android Accessibility Suite from the store).
Have you got any audio or video resources embedded in your web application? Make sure videos are captioned and that audio transcripts are also available.
[Optional] Try to navigate the feature or entire journey while simulating vision problems. Tools such as NoCoffee can help you simulate vision-related issues directly within the browser (e.g. low acuity, colour blindness, low contrast sensitivity, and so on).
List down areas where difficulties were noted. It would also help to use checklists during this process.
Discuss all difficulties encountered during a team meeting – and plan for possible updates/fixes.

Semi-automated testing

Along with manual testing, you can also review your client-side code using browser-based automated test tools.
Browser extensions such as WAVE (Web Accessibility Evaluation Tool) or Axe provide great insights and can help you and your team handle obvious accessibility issues. Nowadays, browsers also ship with their own built-in page audit tools (e.g. Chrome’s Lighthouse). However, both Axe or WAVE come highly recommended.
Also, test your markup using W3C’s markup validation tool. This tool highlights issues with your markup, which might in turn have a significant impact on accessibility (e.g. incorrect nesting of HTML elements, duplicate IDs, and so forth).
List down areas where difficulties were noted. It would also help to use checklists during this process.
Discuss all difficulties encountered during a team meeting – and plan for possible updates/fixes.

Fully-automated testing

Along with manual or semi-automated testing, you should also consider embedding accessibility testing as part of your functional test suite.
Integrate automated accessibility evaluation within your build process as well as CI pipelines using tools such as axe-core and Pa11y-CI (see also Azure axe pipeline and Paypal’s AATT). These tools can help you fail your builds according to pre-established levels of accessibility conformance (e.g. WCAG 2.1 Level AA).
With each build or pull request, developers can understand if there are any potential accessibility issues.
Furthermore, you can build your own in-house accessibility dashboards to monitor your applications across environments (e.g. staging and live). Tools such as Pa11y dashboard can help you achieve this.

The tests discussed here are definitely not comprehensive and are only meant to put your development efforts on the right path. Complete accessibility audits by specialists will give you a true picture of how accessible your technology and digital content is. If you need more assistance, feel free to reach out by clicking on this link.

Step 4: Involve target users and get audited

Expert accessibility audits will give you a true picture of the state of your technology. These audits, which are generally carried out incrementally, are done by domain experts during which rigorous testing (both manual and automated) is carried out, following any applicable legal framework and guidelines at national and international levels. Auditors will generally produce detailed accessibility reports, based on WCAG success criteria across the four guiding principles and at an agreed level of conformance. Audits also generally include technical recommendations for any technology you are working with.

It is also recommended to test your technology with target users. This is not always an easy task, and it might feel slow until you get the logistics sorted. However, organisations such as FITA are there to support you and your team, and will happily review your work.

Do you need more assistance on this matter? Feel free to reach out by clicking on this link.

How do you approach existing projects?

The same process outlined above still applies. Based on previous experience, there are different challenges that can materialise when reviewing existing code:

Use of semantically incorrect markup
Use of non-accessible custom widgets
Use of legacy plugins (e.g. Flash)
Parsing errors
Content management systems producing sub-standard client side code

Unless re-writes are not possible, applying ARIA attributes to non-compliant markup might superficially “fix” some of these issues (e.g. 1 and 2), however, the use of ARIA is to be avoided unless absolutely necessary. W3 state that “If you can use a native HTML element … or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” Furthermore, techniques to make legacy technology, such as Flash or Silverlight accessible can be found on W3’s WCAG Quick Reference (Flash and Silverlight are pre-selected in this link). Parsing errors might be harder to solve unless some code changes are carried out. If you are using an old or exotic (not popular) content management system that is producing substandard code, and on which you have little to no control, then you might need to re-think your way forward – if at all possible, moving away from it. Nevertheless there are usually some hacks one can adopt until a more sustainable solution is found.