DEV Community: Jake Tracey

A developer's perspective: the problem with screen reader testing

Jake Tracey — Wed, 06 Jan 2021 07:16:58 +0000

Screen readers are an essential part of using the web for people who are vision impaired, illiterate or have a learning disability.

Today’s screen readers traverse web pages and applications and read out user interface elements, content and allow users to navigate and interact with the web.

There are many screen readers available for different devices and platforms, each with differing levels of functionality, interfaces and features. The most common are JAWS, NVDA, VoiceOver and TalkBack.

According to the latest WebAIM Screen Reader User Survey, when it comes to desktop screen reader usage, JAWS and NVDA are practically equal in usage, with around 40% of respondents reporting that they use one or the other.

Source: WebAIM

Based on the graph above, there’s a clear pattern over the course of the last 10 years, with NVDA usage increasing as JAWS usage drops, culminating in an inflection point in 2019 when NVDA surpassed JAWS usage for the first time.

As a developer regularly faced with time constraints, I have often wondered: what should be the baseline in terms of testing for screen readers, and what browser and screen reader combinations are the most important to cover in order to achieve the greatest level of WCAG compliance?

An issue of time

Given that almost all web applications developed in 2021 are also used on mobile and therefore require testing on both iOS and Android devices, as well as Windows and macOS for desktop users, providing adequate support for such a broad range of scenarios becomes quite difficult to manage.

Let’s say in a best-case scenario, a given page or feature will be tested on the following combinations:

iOS / VoiceOver
Android / TalkBack
macOS / Chrome / VoiceOver
macOS / Safari / VoiceOver
macOS / Firefox / VoiceOver
Windows / Microsoft Edge / NVDA
Windows / Chrome / NVDA
Windows / Firefox / NVDA
Windows / Microsoft Edge / JAWS
Windows / Chrome / JAWS
Windows / Firefox / JAWS

I should clarify that by “best-case”, I am conveniently leaving out any versions of Internet Explorer, but as frustrating as it may be, including it would add at least another 2 rounds of testing.

It’s also worth noting that WebAIM also recommends using Microsoft Edge with Narrator, but given its low usage, we’ll leave it out (more on this later).

Hypothetically, depending on the size of the functionality or page implemented, let’s say each round of testing takes one hour to complete, assuming the developer has experience with each of these browsers and screen readers.

In this scenario, comprehensively testing screen reader support across all these combinations adds 11 hours of development work – and that’s just to test!

An issue of fragmentation

Web developers will be familiar with the issues surrounding browser version fragmentation, and this problem is compounded when testing with screen readers. Contending with not only varying levels of HTML, Javascript and CSS support in the browser can be tough, and to combat this, polyfills and tools like caniuse.com have made life a lot easier.

When it comes to screen reader version fragmentation, there is very little in the way of either documentation or support for developers. Fixing issues often comes down to a case of trial and error, retesting and hoping for the best.

A piece of information that would be incredibly useful in this area would be penetration of screen reader updates from the vendors. If, for instance, developers knew that there was a high adoption rate of updates among screen reader users, they could be confident that if a screen reader update resolved an issue, patches for older versions could be sunsetted. This approach has worked exceptionally well for browsers such as Chrome and Firefox.

Sadly, there’s not currently any way for a developer to identify the type or version of a screen reader that is being used, so implementing targeted fixes isn’t an option anyway right now.

A case for dedicated accessibility testers

Given the scope and time it takes to properly test across so many devices, browsers and screen readers, having dedicated accessibility testers embedded into teams can significantly increase the quality and speed with which properly accessible applications can be produced.

Let’s face it: developers already have a hard time keeping up with the pace of change in their own domain, let alone the level of knowledge required for comprehensive accessibility auditing.

That is not to say that developers should ignore accessibility completely. However, expecting someone to know about a specific bug on a particular combination of code, browser and screen reader is too much, even for the most experienced accessibility-focused developer.

Why automation isn’t enough

The old saying "a good programmer is a lazy programmer" comes to mind when I think about testing here. Being lazy myself (although possibly not that great of a programmer), I rely on automated tools like axe to do most of my accessibility for me. While the current range of tooling is excellent, and picks up the most obvious issues, when it comes to screen readers there’s no way around it: you need to manually test.

Why? Well, the current state of both browsers and screen reader support is all over the place. To highlight this, the Powermapper website has a neat list of screen reader support for WAI-ARIA attributes. Not throwing shade at any one – things are continuously improving with updates to browsers and screen readers – but the point stands. Current automated testing tools are not going to catch these problems because they essentially test the validity of code, in much the same way as a code linter does.

A compromise, so we can all still get stuff done

Not every team has the luxury of a dedicated accessibility tester, or even a dedicated tester for that matter. Sometimes, you just need to do the best you can, with the resources that you have available.

"When can we stop supporting this?" has been the desperate cry of developers for years when it comes to Internet Explorer 9/10 and most recently 11, and as their usage has dropped, so has the rate of developers losing their hair trying to get their code working.

Which brings me back to Microsoft Edge with Narrator, as mentioned earlier. With 1% of users in that survey, and possibly 0% of users for your application or site, is it worth testing on this combination at all? More specifically, what number of users justifies support, and the testing and development overhead that comes with it?

Windows - Chrome (latest version), NVDA

As of December 2020, Chrome is by far the most popular browser in the world, with 65.3% of users. Later versions of Microsoft Edge utilize the same rendering engine, so there is a high likelihood that if it works in Chrome, it will work similarly in Edge.

Based on the WebAIM stats, it is a safe bet that NVDA will begin to increase its lead over JAWS over the next few years. Given that it is also open-source and free, I can’t help but draw a comparison to the way Firefox overtook Internet Explorer in the 2000s browser wars.

macOS - Safari (latest version), VoiceOver

Safari is a fair distance behind Chrome in terms of users, with 16.7% share as of writing, but it has the benefit of being the default browser in macOS. It is also free, and the support for accessibility features with VoiceOver is second to none. In addition to this, because of the similarity with its mobile counterpart, most likely any issues that are identified in the desktop version will have similar fixes.

iOS - Safari (latest version), VoiceOver

Safari is by far the most popular browser on iOS and all other browsers on iOS use the WebKit rendering engine. VoiceOver is the gold standard for mobile screen readers (and the only option for iOS devices), and as such it makes sense to use this combination for testing iOS accessibility.

Android - Chrome (latest version), TalkBack

In a similar vein to iOS, being the default browser and screen reader combination for Android makes this a simple choice, as it will cover the vast majority of users on this platform. Although manufacturers do include their own browsers and there are quite a few other options on Android, the vast majority of the time they use the inbuilt rendering engine, so the expectation in terms of accessibility should be similar, if not identical, to the Chrome experience.

This is by no means a catch-all solution for everyone. Each circumstance will be different, and the best course of action would be to engage your users and ask rather than trying to make the decision for them.

The reality is that if your site or application’s design or functionality looks bad or works poorly for a large enough number of your users because it does not support the software that they use, it can have potential ramifications to your business, through sales or reputation. Similarly, poor accessibility will have a negative impact if your users are using older versions of screen readers and browser combinations.

But what about JAWS, ZoomText, System Access, insert screen reader here?

At the risk of being slightly incendiary, I dislike the idea of paying for something that I can get for free. NVDA is a project that has brought screen readers to everybody – including those without the financial means to pay for it – so I support it. Along with the clear trajectory of its usage uptake, it is not unreasonable to expect that the majority of users will adopt it in the next 5 to 10 years.

At the end of the day, however, your best bet when it comes to identifying where your testing efforts should be placed is to talk to your users to find out what their needs are and what software they use. If you don’t have access to this information, the proposed testing scope above will suffice for the vast majority of your site or application’s users, and most likely will continue to do so in the years to come.

Originally published at jaketracey.com

The best web accessibility tools for developers in 2021

Jake Tracey — Sun, 03 Jan 2021 06:27:51 +0000

The quality of the tools you use defines the speed with which you can diagnose and resolve problems.

Each year the landscape changes dramatically in web technologies, and of late the tooling for accessibility is no exception.

I’ve divided this article into 4 categories - resources, development tools, continuous integration and screen readers.

Resources

These are the pages that I keep bookmarked for reference and to learn new techniques.

There are a number of great accessibility blogs on the web which I suggest browsing - a good jumping off point is available at Digital A11y.

Development tools

axe - axe has quickly become the defacto standard for automated accessibility testing. Deque's axe-core testing engine provides the under the hood implementation for most common tools, and they also provide a free Chrome extension that quickly identifies any in page errors for most common issues while providing guidance on how to resolve them. Definitely my first port of call when testing any new code.
pa11y - pa11y is an automated testing tool based on axe-core that can be run on your development environment as part of your commit hooks or front-end build pipeline. It's extremely configurable so you can run automated tests for different accessibility standards and viewports, ignoring specific WCAG rule sets as well as triggering actions on pages as a part of your test suite. @f3igao's wonderful blog post, How to automate web accessibility testing is a great starting off point if you are looking to fully integrate pa11y with your front-end build.
DomainAccessibilityAudit - I found this tool while researching ways to test an entire website for a11y issues and this was a perfect fit. You can feed it a root URL to start testing on and it will scrape all links on all subsequent pages and perform an audit, essentially crawling the entire site and producing a report of a11y issues. You can also input a sitemap.xml if you want to test a specific set of pages instead of crawling the entire site.
Accessibility insights for web - Microsoft's commitment to accessible technologies shines with their free Chrome extension and provides another useful interface to the axe-core framework.
Siteimprove Accessibility Checker - The Siteimprove browser extension provides one of the most comprehensive interfaces to resolving issues with detailed recommendations on how to fix them. Highly recommended to keep in your toolbox.
Lighthouse - Don't have time or access to install software to run a quick a11y check? Lighthouse comes built in with Chrome DevTools and provides a fast, easy to understand issue checker that integrates perfectly with the Chrome browser. It also offers other suggestions in terms of improving page performance, server configuration and insights into using progressive web applications.

Continuous integration

Catching issues before they are in production is one of the major benefits of adding accessibility tooling to your CI pipeline. Recently there has been huge progress in the ease of integration and reporting in this space, which I expect will continue to improve over the next year.

pa11y-ci - A set of command line tools for pa11y, pa11y-ci gives you the opportunity to run your suite of pa11y tests on your CI server.
lighthouse-ci - If you're looking to run a comprehensive set of tests in your CI environment, lighthouse-ci brings all the power of Google's Lighthouse app to the table. In addition to accessibility checks, lighthouse-ci will report on your app's performance, SEO and best practices in one of the most polished standalone reports available.

Screen readers

JAWS - JAWS is the most popular and oldest screen reader that is still in use. It represents a huge proportion of screen reader users so it is an essential tool when testing for issues.
NVDA - NVDA is my screen reader of choice for testing because it's open source and free. It's also updated quite frequently and in my experience, has less quirks than JAWS. I expect in the coming years NVDA will overtake JAWS in terms of popularity, so if you were to pick one to learn, NVDA would be it.
VoiceOver - VoiceOver is the defacto standard for screen readers on iOS and Mac OS X. It is extremely easy to use and the documentation is incredible. The vast majority of screen reader users on mobile are using VoiceOver so it is the most important tool you can use if a mobile audience is your primary demographic.
TalkBack - TalkBack is the Android OS screen reader. Similarly to VoiceOver, when developing for the mobile web, it is essential to test using TalkBack. Unfortunately, the OS version fragmentation on Android devices varies wildly, so it may be best in your particular scenario to test using a couple of versions older than the latest Android OS when conducting audits using TalkBack.

I hope you find this list helpful - each year I will add an additional update with any new tools I have discovered, and provide any comments on how the landscape is progressing.

Originally published at jaketracey.com

Styling accessible HTML file inputs

Jake Tracey — Fri, 01 Jan 2021 00:15:00 +0000

The HTML file input is one of the weirder elements I've come across. Although it's used pretty extensively, the default implementation leaves
a lot to be desired without resorting to Javascript. I investigated what could be done using CSS only in terms of styling and have had some good results.

It's just one one element... but is it?

The first thing you notice when including <input type="file" /> is that it has two parts that would normally be distinct element - a button to initiate the operating system file picker dialog, and a line of text indicating to the user that they should choose a file or if a file has been chosen, display the path or name of that file.

This begs the question - how do you style the two separate parts of this (one) element?

The general consensus online is by linking a <label> element to the <input> and hiding the actual <input>, the <label> becomes a focusable/clickable facsimile of the actual element, with which you can style to your liking. You can then replicate the functionality of the text displaying the filename with Javascript.

Hoping to not have to reinvent the functionality of the <input> itself, let's try to find a way using just CSS.

Styling the file input

To style the <input>, you can use the CSS attribute selector:

input[type="file"] {
  // your code here
}

On Firefox, Blink and Webkit based browsers, this will allow you to customize the styling of the file name text, position the element and add spacing, but it does not
impact the button itself. On IE11, apart from positioning and spacing, this selector is practically useless. Moving on...

Pseudo selectors

I'll start this off with the bad news - there is no single pseudo selector that handles <input type="file"> everywhere. Each browser (Chrome/Firefox/IE11) has their own implementation of how to address the insides of the html±<input> with varying levels of control. Here's a basic rundown:

Chrome (Blink/Webkit browsers)

input[type="file"]::-webkit-file-upload-button {
    // your code here
}

Firefox

input[type="file"]::file-selector-button {
    // your code here
}

A few things to note here. Both Firefox and Blink/Chrome based browsers have selectors that allow practically full customization of the file selector button.
You can add hover/focus/active states using their selectors, for example:

input[type="file"]:hover::-webkit-file-upload-button {
  // hover state css
}

input[type="file"]:active::-webkit-file-upload-button {
  // active state css
}

input[type="file"]:focus::-webkit-file-upload-button {
  // focus state css
}

The actual label of the button does not appear to be customizable, even using the content CSS property. At the time of writing both use sane defaults for these,
so if you must change the button label further, using the Javascript + <label> trick is your best bet.

You can even modify the positioning of the file name text by setting display: block on both elements, for a nicer 'file name under button' look.

I noticed some strangeness around box-shadow property not rendering correctly due to the constraints of the containing box model. By adding some padding to the
<input> itself it will give the element space to render any content inside.

Internet Explorer 11

input[type="file"]::-ms-value {
    // file name styles
}

input[type="file"]::-ms-browse {
    // button styles
}

IE11 provides pseudo elements to modify the styling of both the input and the file name text - with some caveats. The IE11 file upload widget by default renders a text box before the browse button, and this does not render text inside of it (e.g. Choose file) prior to a user selecting one.

This can create a strange look if you remove the borders from the text box using ::-ms-value - I opted to style that box the same as other text inputs in the design
to maintain some consistency for the user.

When a file is selected, IE11 also writes the entire path to the file on your local system, somewhat reducing the usefulness of this box if it is not extremely wide.

I was also unable to modify the actual layout/order of the items in the rendered widget beyond width/height/padding modifications.

Due to IE11's support becoming smaller and smaller each day, I compromised on the final result by applying the same button styles as the Blind/Firefox counterparts, but retaining the look and feel of a text input on the file name area so that it was relatively consistent for the user.

Conclusion

It is entirely possible to style <input type="file" /> on modern browsers in a way that does not impact the visual look and feel of
your design. Although not as powerful as a full fledged custom file upload widget, because it is default browser functionality and is widely supported, thanks to the highly vendor specific selectors that are available you can provide an accessible, good looking utility to upload files without any Javascript.

Originally published at jaketracey.com

Accessible Inverted Colors

Jake Tracey — Thu, 31 Dec 2020 04:52:26 +0000

Recently when developing styles for accessible form inputs an interesting challenge came up - how to handle the inverted color schemes that are available on Windows computers.

For reference, to switch a Windows PC to use inverted colors, you can use the keyboard shortcut

Shift+Alt+PrtScr

By default, form inputs like html±<input> and html±<textarea> will look fine and the colors will invert properly.

However, if you are doing custom styling without using the border property, for example using box-shadow and hiding the border in a standard color view, you may notice that box shadows on these elements do not appear in the inverted mode, creating an accessiblity issue for users that are using the inverted mode.

A quick trick to fix this issue is by adding a transparent border to those elements, like so:

border: 1px solid transparent;

This could potentially create a gap if you are using a combination of inset and outside box-shadow properties - so we can use a media query to specify when it should be used - in this case, when the inverted mode is active.

There are two useful media queries that are currently available that can achieve this goal:

ms-high-contrast: active and forced-colors: active

The first media query works on older versions of Internet Explorer, and forced-colors works on (most) modern browsers.

The final code should look something like this:

@media screen and (-ms-high-contrast: active), (forced-colors: active) {
  border: 1px solid transparent;
}

A side note: currently neither of these media queries appear to work on the latest Firefox as of writing this.

Both are fully supported in the latest Microsoft Edge, which is the best supported browser when using inverted color mode.

Originally published at https://jaketracey.com