My name is Aaron Page. I am Allyant’s VP 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 do I mean by “Web Applications”?
For the purposes of this article, the term “web applications” refers to complex web apps that you interact with from within the web browser and which override the traditional keyboard behavior found on a conventional website. Examples of popular “web applications” include Google Docs, Google Sheets, Microsoft365 Web Apps, Slack, and many, many more.
In some cases, a website/service may fall between a conventional website and a full-on web application. For example, Twitter/X has keyboard shortcuts available for many functions but doesn’t generally override keyboard behavior and take control like a typical web application does. Other examples of this include YouTube, Vimeo, and other services that provide some limited keyboard-specific shortcuts within an overall web page.
Keyboard Shortcuts on the internet
In my previous article on navigating websites as a blind user of screen-reading software, I mentioned how important landmarks, headings, and other structural elements are to effectively navigate a site using a screen reader. The trick is that most of these keyboard shortcuts are unavailable to screen reader users when navigating a web application.
When a web page is opened using screen reading software, the screen reader essentially creates its own “virtual” version of the web page based on the contents of the accessibility tree. What the user is hearing and largely moving through is this “virtual” version.
This enables the screen reading software to control the navigation and to intercept all keyboard shortcuts that the user enters.
The result is that when a user presses the H key, they move between headings; when they press the L key, they can jump to lists, and so on.
Keyboard Shortcuts on Web Applications
With a web application, this is not the case. The web application is responsible for handling all of the keyboard shortcuts rather than the screen reading software. This is essential when you think about it —in order for a user to type in a document in a web application like Google Docs, their keystrokes cannot be intercepted by the screen reading software, so the characters are entered in the document.
For a user to traverse the message history in Slack with the arrow keys, the screen reading software needs to not intercept the up/down arrow keystrokes and try to move focus since Slack will instead move one message at a time through the history.
Advantages and Disadvantages of Web Applications
When considering whether to approach your tool/service as a web application or instead as a web page, it is useful to think about some of the advantages/disadvantages of this approach to users.
Advantages
- Specific keyboard shortcuts can be created for a wide variety of tasks.
- More control over how content will be announced to the user.
- Power users who fully utilize available keyboard shortcuts can become highly efficient with the application.
Disadvantages
- The application is responsible for ensuring the user can navigate and access all of the application’s information. This means you must map out how the user will reach every piece of text, every panel, every object, etc.
- The application may appear inaccessible or unusable to novice screen reader users and/or new users.
- Screen reader users, in particular, must learn the application-specific keyboard shortcuts to effectively navigate and use the application. Documentation, and making that documentation easy to find, is critical.
- Essentially, screen reader users need to forget most everything they know about navigating using their screen reading software, as most screen reader keyboard shortcuts used to traverse web pages will become unavailable.
Should Developers Avoid Building Services as Web Applications?
Ultimately, there are instances where it is inevitable that a tool/service be designed as a web application. Designing your service as a web application may be necessary to provide all the features/functionality your service requires.
However, in many cases, it may be possible to provide all of the desired functionality while adhering to traditional web elements and not overriding keyboard focus, as seen in a web application.
For example, tools like the Allyant HUB, Google Search, and many other online tools/services provide significant, complex functionality but do so in a way that utilizes traditional web elements and allows the screen reading software to manage focus no differently than a web page.
If it is possible to approach your tool/service as a web page instead of a web application, that may flatten the learning curve for visitors to the application.
In particular, for users of screen reading software, who will be able to continue to rely on standard web navigation shortcuts rather than having to learn a new set of application-specific shortcuts.
Approaching your tool/service as a web page rather than a web application will also likely reduce development time and effort since most screen reader and keyboard navigation will continue to be handled by the browser rather than the application.
What about X/Twitter, YouTube, and other services which are “on the fence”?
The advantage of the approach used for services like X/Twitter, YouTube, etc., is that the user can have the best of both worlds. Keyboard shortcuts are available for keyboard users, and screen reader users can usually treat these just as a web page and use standard screen reader navigation commands.
The disadvantage is that users of screen reading software may not be able to fully utilize all of the available keyboard shortcuts, or they may need to take an additional step to make the keyboard shortcut work.
As the page has not been marked up as a web application, and the screen reading software remains in its traditional reading mode for web content, keyboard shortcuts will most likely be intercepted by the screen reading software.
For example, when playing songs on YouTube Music, you can press “K” to jump to the previous song, and by pressing “J,” you jump to the next song. However, if I, as a JAWS user, press “K,” it triggers the JAWS command to jump to the next place marker, and pressing “J” triggers JAWS’ “Jump to line” feature. The screen reader intercepts these keyboard shortcuts, as they are used to help navigate quickly around a web page.
To resolve this, most screen readers offer a “pass-thru” feature, which essentially tells the screen reading software to allow the next keyboard command to go through to the web browser/page and not to trigger a screen reader-specific command.
On JAWS, this keyboard shortcut is Insert+3.
Using the example above from YouTube Music, if I want to use the keyboard shortcut “J” to jump to the next song, I first have to press Insert+3, then the letter “J”.
Alternatively, the user can force the screen reader into web applications mode, which allows all keyboard shortcuts to pass-thru until the mode is switched back off.
Unfortunately, these are more advanced features/functionality of screen reading software, and many users may be unfamiliar with how to do this or maybe uncomfortable switching between modes.
Conclusion
Web applications are extremely powerful tools/services and, when designed properly, can be made accessible to users of all abilities.
It is critical when designing a complex web application to consider how screen reader and keyboard users will navigate the application and access various elements.
If it is possible to develop your service and all of its needed functionality without taking full control of keyboard navigation, then that may be preferred as it makes the service easier for visitors to understand without referring to application-specific documentation, and it will also save development resources by not having to implement all the necessary keyboard handling in the application itself.
If your service must be designed as a web application, it is critical to work with accessibility experts to ensure its features/functionality are accessible, test the application with users with disabilities to ensure it works as expected, provide documentation for users on how to use the application via the keyboard and with screen reading software and make that documentation easy to find.
