[...] Let me state emphatically and unequivocally that the preference of the National Federation of the Blind is for all technology, including websites, to be accessible at implementation through the integration of development best practices that include accessibility during the design and development phase. This has come to be referred to as "born accessible." Moreover, we encourage that companies strive to enculturate accessibility throughout the entire organization.
With the proper staff training, a company's existing information technology resources can be used to code accessible webpages, produce accessible web content, prepare accessible documents, and procure accessible third-party software, devices, and equipment. This strategy helps an organization increase diversity and inclusion, meet compliance requirements, and increase the value and effectiveness of its products and services. Conversely, the overlay only professes to address the accessibility of the website; it does nothing to assist the executives, managers, and frontline workers to understand the policies, procedures, and systems required to enculturate accessibility.
There are those who feel we should condemn the use of overlays and advocate against any further implementation or future development. Although we intend to hold overlay companies accountable for what they do and what they say they can do, we are not prepared to make a judgment that artificial intelligence cannot be used in the future to solve coding problems.
It is important to note that we condemn the deceptive marketing strategies being used by some overlay companies but do not unequivocally condemn the use of overlays. By using the overlay to attempt to provide fundamental accessibility while working to correct the underlying problems with the code, the overlay strategy may be successfully used as an interim step to repair an inaccessible website. This is very much like securing a wound with a tourniquet until proper medical attention can be provided. We offer the caution that this strategy should not be overused because, like a tourniquet, if used incorrectly, it can harm more than heal. If the company does not have the internal knowledge and skill to correct the problem once it has been identified, the implementation of an overlay strategy may deter implementation of a more permanent solution.
A lot of that information can be hidden to the average developer unless they are checking the accessibility inspectors across browsers or testing with a suite of screen readers. This is one of the reasons I always advocate for making your styles lean on structure and attributes from the DOM, to make it easier to spot when something is amiss.
It is also, in my opinion, a way to reduce the surface area for accessibility bugs. If your sort icon orientation is keyed to the ARIA property that conveys that state programmatically, then getting that ARIA property wrong will have two effects — a broken interface and a weird icon. Addressing the accessibility issue will fix the visual style.
[...] Instead of preaching concepts, let me toss some examples out. Each of these links to a blog post where I explain the styles, how the selector is keying off the HTML, what WCAG Success Criteria they help support, and if there are any gotchas. Please read at least the linked sections of those posts for more detail.
Many of the global ARIA states (but not properties) are great as styling hooks. Getting familiar with all ARIA states and properties that are available across widgets and other uses can be handy as well.
Every time you come up with a style that reflects a state or property of something (open, closed, expanded, collapsed, on, off, checked, disabled, busy, locked, selected, sobbing uncontrollably), do not use a class. At least not at first. Look at the programmatic change that happens to the underlying HTML that makes that thing happen.
Try to use that as your styling hook instead. Write it in a way where if that change does not happen, neither does your style.
After a decade of declines, JAWS is once again reported as the most common primary screen reader, with NVDA and VoiceOver both showing notable decreases in primary usage over the last two years.
Respondents with disabilities are more likely to use JAWS and NVDA and less likely to use VoiceOver as their primary screen reader than respondents without disabilities. 5.5% of respondents with disabilities primarily use VoiceOver, compared to 18.5% of respondents without disabilities.
Primary usage varied greatly by region. JAWS usage was much higher than NVDA in Australia (71.4% vs. 21.4%) and North America (63.1% vs. 19.4%), though JAWS usage was lower than NVDA in Europe (40.2% vs. 41.6%), Africa/Middle East (38.5% vs. 61.5%), and Asia (31.5% vs. 39.7%).
Usage of JAWS and Narrator increased notably over the last two years, with NVDA and VoiceOver usage decreasing. Narrator—freely available in Windows for several years—is the primary screen reader of only .5% of respondents, but commonly used by 41.3% of respondents (up from 21.4% in 2017 and 30.3% in 2019).
71.3% of respondents use more than one desktop/laptop screen reader. This was up from 53% in July 2015 and 68% in 2017. 39% use three or more, and 15.9% use four or more different screen readers. VoiceOver users most commonly use additional screen readers, which is notable since the other screen readers run almost exclusively on Windows.
There are many combinations of browsers and screen readers in use, with JAWS with Chrome by far the most common.
Respondents indicating that they are very or somewhat satisfied by their primary screen reader:
- NVDA - 97.3%
- JAWS - 95.3%
- VoiceOver - 93.7%
- ZoomText/Fusion - 91.5%
- Narrator - 87.5%
Respondents with disabilities used iOS devices at a higher rate than those without disabilities. Usage of iOS devices was significantly higher in North America (82%), Australia (75%), and Europe/UK (71%) than in Africa/Middle East (54%), South America (33%), and Asia (27%). Respondents with more advanced screen reader and internet proficiency were much more likely to use iOS over Android.
Perception of the state of web accessibility has generally not changed in recent years. Respondents without disabilities tend to be more positive about recent progress (47.4% thought it has become more accessible) than those with disabilities (38.6% thought it has become more accessible).
The frequent use of landmarks and regions has continually decreased from 43.8% in 2014, to 38.6% in 2015, to 30.5% in 2017, to 26.6% in 2019, to 25.6% on this survey. It's difficult to know the reasons for this. It could be due to infrequent or improper usage of landmarks/regions in pages. Or perhaps because other mechanisms are continually better.
Navigating headings remains the predominant method for finding page information. Those with advanced screen reader proficiency are much more likely to use headings (76%) than those with beginner proficiency (41%), who are more likely to read through the page or use the "Find" feature.
While 25.6% of respondents indicate that they always or often use landmarks when they are present, only 3.2% use this as a primary method for finding information on a lengthy web page.
The usefulness of proper heading structures is very high, with 85.7% of respondents finding heading levels very or somewhat useful.
I created Auto VO to make it easier for developers, PMs, and QA to more quickly perform repeatable, automated tests with real assistive technology, without the intimidation factor of learning how to use a screen reader.
[...] You may have heard guidance to "just turn on your screen reader and listen" to give you a sense of the blind experience. I think this is misguided. Screen readers are sophisticated applications that can take months or years to master, and are overwhelming at first. Using it haphazardly to simulate the blind experience might lead you to feel sorry for blind people, or worse, try to "fix" the experience the wrong ways.
I've seen people panic when they enable VoiceOver, not knowing how to turn it off. Auto-VO manages the lifecycle of the screen reader for you. It automates the launch, control, and closing of VoiceOver, so you don't have to. Instead of trying to listen and keep up, the output is returned as text, which you can then read, evaluate, and capture for later as a reference in a bug or for automated snapshotting.
- An SVG has an implicit WAI-ARIA role="graphics-document".
- In general it is best not to change the implicit role of the SVG.
- If an SVG only contains a specific type of content, such as an image, you might assign a role="img" or, in the case of an icon, role="graphics-symbol".
- Assigning role="presentation" should be avoided, because it doesn't hide the SVG. It just cancels the native role.
- Assistive technologies will still read elements that have been given a role="presentation", they just won't give them any semantic meaning. For example, a layout table might be given a role of presentation because you don't want assistive technologies to read out row and cell information, but users can still access the content in the cells.
- In order to hide an SVG, it is best to give it an attribute of aria-hidden="true". This functions in a similar way to display:none in CSS.
- More on the difference between role="presentation" and aria-hidden="true".