My name is Aaron Page. I am Allyant’s Director of Accessibility, and I am blind. I was born with congenital glaucoma and lost my remaining functional vision 15 – 16 years ago. I want to start by stating that my experiences are my own, and they are affected by my disability, my past experiences, and the assistive technologies I use.
My experience may not be the same as other blind / low-vision users, and will certainly be different from the experience persons with other disabilities, such as motor/dexterity or cognitive disabilities, may have as they try to access the Web.
When accessing the Web, I primarily do so using the following devices and assistive technologies:
- A Dell XPS 13 laptop running Windows 11 w/JAWS for Windows as the primary screen reader
- An iPhone 13 Pro Max running iOS 17 w/VoiceOver as the primary screen reader.
In this article, we’ll talk about what it is like to access websites and applications using the first device I mentioned above – a desktop/laptop computer running Windows and using the JAWS screen reader.
What does a screen reader sound like?
For those who have never heard a screen reader in action, it can be an illuminating experience.
Below is a paragraph of text from the Allyant website, and following that is a short clip of this text being read out by my screen reader. Keep in mind that this is how my screen reader sounds when browsing websites, reading emails, etc., but this is only 60-65% of the maximum speed supported by my screen reader.
“At Allyant, we believe every organization’s journey toward equitable access should be simple and seamless—eliminating the worry, stress, and uncertainty often associated with accessibility. For this reason, we offer many accessibility services and software solutions, spanning print and digital document remediation services, document remediation software, and digital accessibility auditing.”
What makes a website bad/inaccessible?
On one hand, you could say the answer to this is easy – a site that doesn’t conform to the Web Content Accessibility Guidelines. On the other hand, as a user, I have encountered my fair share of sites that might not be WCAG-conformant but were still perfectly usable to me as a user of screen-reading software.
The opposite can also be true – a site or web application may technically conform to WCAG but be so clunky/non-intuitive as to be functionally unusable to me and other users of screen reading software.
Speaking just as a user going to a website and trying to access it, there are a few things that will cause me to give up on the site in relatively short order:
- Lack of useful headings – Headings provide an essential navigational tool for users of screen reading software. Properly marking headings on a page or in a document allows screen reader users to quickly jump to the desired heading/section of the page, similar to how a sighted user may skim through a page looking for big, bold text. It is important to note that what I mean here is when a site doesn’t have any headings or the headings provided are extremely limited. I am not talking about a site that has headings, but the heading levels are in an illogical order, or heading levels are skipped – whether the headings are logical or not, they are useful as a navigation tool as long as they are there. If a site has no headings or limited headings, navigating around each page will be more difficult/time-consuming.
- Lack of useful landmarks/regions – Landmarks/regions provide a similar function to headings in that they allow users of screen reading software to jump to sections of the page; however, landmarks/regions are usually more broad, such as the site header, footer, main content, navigation, etc. On most sites, decent landmarks/regions are provided by virtue of using good/semantic HTML. If your site doesn’t have good landmarks/regions, then users of screen reading software may find it more difficult/time-consuming to jump back to the site header, or to the main navigation, and so on. While not quite as critical as headings, if a site lacks both headings and landmarks/regions, I will usually close the page and not bother.
- Accessibility Overlay tools – These tools usually stand out like a sore thumb to users of screen reading software upon reaching a site. Some of these tools will automatically fire off alert messages to inform users of screen reading software that they are present and to prompt the user to enable the overlay functionality. I could write an entire article about overlays in general, but suffice it to say that on most sites, if an overlay is present, it is impossible to ignore the overlay tool. Some overlays will attempt to automatically detect what type of disability you have or assistive technology you use and apply a corresponding “profile.” As someone with a disability, I do not want to have to disclose my disability when I visit a site, or apply a disability-specific profile, or use the screen reading/text-to-speech functionality provided by an overlay tool. If a site is accessible, it should just work for me without doing any of that.
If I visit a site and encounter any of these, I usually just close the page and try to find a different site that can serve my needs.
What makes a website good/accessible?
Not having any of the above-mentioned issues is a good start. Ensuring your site is WCAG-conformant is always the best way to ensure your site is accessible for all, but as mentioned earlier, just because a site is not WCAG-conformant doesn’t mean it is not usable or that it is inaccessible to me as a user of screen reading software.
A few things I look for that can give me a quick clue as to whether or not the site is accessible/usable include:
- Navigation Menus & Site Search – It is surprising the frequency with which I visit a site and find the site’s main navigation menus or the site search is not accessible. If I can’t access the menu to navigate to inner site pages or use the site search to locate products or information, then how can I really use the site? If these gateways to the site are accessible/usable, then that often bodes well for being able to use the site, regardless of whether or not it is fully WCAG conformant.
- Skip Links & Accessibility Statement – The funny thing is, I, as a user of screen reading software, usually don’t activate/use skip links. My screen reading software provides other tools, such as navigating by heading or landmark, which are often more useful. According to the most recent WebAIM Screen Reader User Survey, I am not alone, as only about 30% of respondents said they either “Always” or “Often” use skip links. However, even though I don’t need to use the skip link, it can be a great barometer of whether the site has accessibility on its radar. This goes doubly so for Accessibility Statements – I don’t usually read them on sites I visit. Still, I do notice when an Accessibility Statement is provided and take it as a good/positive sign when they do.
- Critical Form Controls – You can spend hours and hours making a site accessible, but if the controls used to select a product size/color option, submit your contact form, or proceed from the cart to the checkout are inaccessible, nothing else really matters. Especially when looking at an e-commerce site or a site where I will be filling out a form, a big question is whether or not those critical controls you will need to interact with are accessible. The most common examples of this I encounter are product size, color, and fit options on e-commerce sites. These controls are very often created using custom HTML elements rather than semantic controls like radio buttons and, as a result, are very often inaccessible. If I can’t select the size and color I want, then it doesn’t matter that you have excellent alternative text on your product images, good heading structure, etc.
My experience of using Web Applications
Web applications have been gaining popularity in recent years and are slowly replacing traditional desktop-style applications. However, as a user of screen reading software, I have mixed experiences with web applications.
Since web applications are, by their nature, content you interact with from within a web browser, they typically have a higher baseline accessibility compared to desktop applications. I have encountered plenty of desktop applications where I could do nothing, read nothing, interact with nothing, and the application was essentially a blank void as far as my screen reader was concerned.
However, this doesn’t tend to be the case with web applications – usually, there will be at least some content within the web application that will be perceivable to a screen reader user, even if that is just text.
As a user, the most challenging part with web applications is often learning how to interact with them, what keyboard shortcuts must be used, etc.
When navigating a web page, there are standard keyboard shortcuts provided by the screen reading software, for example, pressing H to move by headings, L to move to lists, and commands to read by paragraph, line, word, and so on.
However, when using a web application, the user has to largely disregard all of their screen reader-specific keyboard shortcuts and instead use shortcuts provided by and specifically for that application.
For example, to move to the next post on Twitter, you must press the K key; to move to new/unread messages in Slack, you must press Alt+Shift+DownArrow; and to move between panels in Microsoft Teams, you must use Ctrl+F6.
Learning application-specific keyboard shortcuts can often be frustrating for a screen reader user. I have spent years learning how to operate my screen reader and all of its specific shortcuts, just to have to forget all that and learn the keyboard shortcuts to operate a single, specific application.
This is one reason why simply providing a keyboard shortcut may not be as good a solution as it may seem – how will users learn about the keyboard shortcuts, how will users keep track of the available keyboard shortcuts, do the keyboard shortcuts interfere with other shortcuts provided by the operating system or common screen readers, do you have the necessary markup to ensure keyboard shortcuts are properly passed from the screen reader to the browser and more.
Given all this, it is always preferable to go with simple designs using semantic HTML elements, where you can let the screen reader interact with content like a web page instead of forcing it to operate like a web application.
Conclusion
Modern screen readers are amazingly powerful tools, and they provide many features and functionality to help users navigate and interact with even the most inaccessible sites. Simply having accessibility conformance issues doesn’t necessarily mean your site is inoperable or unusable, but the best and only real way to ensure WCAG conformance and genuine usability is through live user testing by users with disabilities who use these assistive technologies daily.
This is even more true when dealing with web applications, as their complex and unique interactions require even more user testing to ensure the application is intuitive and operates as expected when used with a screen reader or other assistive technology.
By partnering with Allyant, whose audit process is centered on paired auditing with live users with disabilities, you can ensure your websites and applications conform to accessibility standards and are effective and usable to all.
