NearForm Accessibility Experts Discuss Web Accessibility on Design Talk Podcast

In a recent episode of the Design Talk podcast, NearForm's Jack Clark,  Senior Software Developer, and Matt Obee, Senior Product Designer, discussed accessible first design.

We took a look at the key insights from this podcast. Listen to the full episode of the podcast where Jack and Matt explore how tools can be used to evaluate the accessibility of a website or app, the future of accessible authentication, the promises and dangers of overlays, and the importance of 'shift left'.

To evaluate a website you need to first and foremost understand accessibility standards. There are standards called the Web Content Accessibility Guidelines (WCAG) , which are an international standard built into laws and regulations across the globe. WCAG is the global go-to standard for evaluating websites and native apps and is made up of 78 success criteria over four categories: perceivability, operability, understandability, and robustness. These standards provide a consistent way to evaluate how websites are usable by people with disabilities.

There are various tools across several tooling categories now available to help evaluate websites against WCAG, but these are not fully automatable. Ultimately, there is always going to be some level of manual expertise required.

Firstly, we have accessibility checkers (such as Axe and Wave ), which take the form of browser extensions that take snapshots of a website at a point in time and analyse them to check for common violations against WCAG guidelines. These checkers can automate a lot of tasks that are time-consuming and free up an accessibility checker to do testing and can cover between 30-40% of WCAG criteria. This includes looking at semantic code and colour contrast for readability, all the way to screening for alt text provision. We use these tools daily and find them really helpful.

Secondly, we have tools for guided accessibility testing, which bring to the forefront potential issues on websites that aren’t easy to automate and need human intervention. Examples include whether alt text provided for an image actually makes sense - this is subjective and requires human testing. These tools can pull up the alt text and provide it for human review.

Thirdly, we have simulators, which show what a website might look like for people with different visual impairments, such as colour blindness. These tools don’t check against WCAG guidelines, but rather allow us to operate with empathy, enabling us to better understand how others perceive the sites we build. It is very important to note that these tools are absolutely not a replacement for user testing; having people with visual impairments review and test the site themselves remains critical. However, simulators can provide people who do not have accessibility needs with a better level of understanding. Related Read: The Importance of Understanding and Building Accessible Web Applications

CAPTCHAs provide a challenge to accessibility as they typically rely on people being able to see things. If you are blind, this naturally isn’t going to work. Other CAPTCHAs use puzzles, which can present difficulties for people who struggle with cognitive puzzles. The upcoming version of WCAG has a new guideline around accessible authentication: it can’t rely on cognitive function tests. We are likely going to see more authentication via password managers, biometric scanning, magic links, or other examples of two-factor authentication using USB dongles and plugins.

These overlay tools try to fix accessibility problems automatically, by detecting failures according to WCAG  and fixing things in the browser. Unfortunately, this often leads to band-aid solutions that fail to address the underlying defect, as well as many problems being missed due to a lack of manual testing. In our opinion, overlays are not good, however, they have a lot of investment, so are likely to be around for a while.

Over 60% of accessibility issues arise in the design phase and are detected in development or testing. The later an issue is caught, the longer and more expensive it will be to fix. At NearForm, we go for a shift-left approach, where we move accessibility from the end to the beginning of the planning process. This enables solutions to be better integrated and more robust while saving developers from having to do extra work.

In the engineering phase, what commonly happens is that we do an audit of what needs fixing once the product is ready for release. When this happens, the feedback loop is long and expensive as many issues have to go back to design, leading to re-designs. We can take a more iterative approach by using the tools we discussed earlier during the development phase to catch issues as we build each feature.

Ultimately, awareness and education are critical in this process. Asking “is this accessible?” during the process is essential. While not everyone has to be an accessibility specialist, getting those involved to ask the right people the right questions is critical to ensure that accessibility problems are addressed correctly. Related Read: The Bottom Line on Accessible Web Products

We are still working on this as we go. A lot of change management and awareness building is needed.