My favorite screen reader

Long story-short, the winner is JAWS. It's standard key commands are familiar and similar enough to the other screen readers, it has the power to be incredibly customized to your needs if you want but doesn't require it to use, and it's the most supported tool generally.

JAWS on Windows with Chrome 

JAWS logo
Liked:

  • having more options to pull up lists of specific elements to navigate
  • the ability to customize my experience more so that it's catered to my preferences
Disliked:
  • Not much really, but it's not free
Favorite Key Commands:
  • Q : to skip to main region and start reading the content
  • CTRL + INS + down arrow : to start reading where my last focus was when I needed to pause and take notes on something
  • INS + F6 : find the spot on the page I wanted to read based on the headings instead of having to tab around

Narrator on Windows with Edge

Liked: 
  • Generally easy to use and navigate
Disliked:
  • It doesn't have the same robust list options as JAWS that make viewing a list of headers or links useful
  • Did not like having to use Edge as a browser

NVDA on Windows with Firefox

Liked:
  • The unique sounds it played for certain interactable elements and actions
  • So far has the best default human-robot voice
Disliked:
  • No visual focus when reading page text (this may have been a setting I had not configured)
  • The speed only goes up to 100 which was not as fast as other screen readers
  • It spoke content that I was hovering over with my mouse, and at first it was useful, but I can see that getting disorienting if you're a sighted user. If I was scrolling the page down to find where the text being read, I'd lose my place due to the cursor hovering over text which it then paused to read.
  • I experienced some issues with Confluence keyboard shortcuts while using NVDA. It seems to have conflicted with the screen reader short cuts.

    Favorite Key Commands:

    • CTRL : to stop reading
    • H : next heading
    • INS + Down Arrow : read continuously
    • INS + F7 : list headings, buttons, links, landmarks

    VoiceOver on Mac

    Actually I really disliked this one the most and found it incredibly frustrating to use. It felt like all the things that typically make using a Mac easy were getting in the way because it was designed under "think different." In this case I feel like being different for the sake of being different just made it impossible to anticipate functionality.

    Popular posts from this blog

    Practice Site: Keyboard Accessible Tooltip Fail

    Image
    While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
    Read more

    Boiling the Ocean of Accessibility

    Image
    It can be daunting to look at an entire platform and be told, "Ok, now make it accessible." You don't need revolutionary planning, or exhaustive sprints to start. Including some accessibility work into regular sprint planning can offset any extra LOE, and you can start adding accessibility requirements right into each ticket. In a blog post for MediSked that I wrote in 2021, " Modular Accessibility for All Users ", I outline some easy ways to incorporate real accessibility into the SDLC, and start making progress to a completely accessible product as a whole. Some of the basics include: Using a third-party library of components that have accessibility built in. (Like Kendo UI for VUE or Deque Code Library )You'll still need to adjust and apply them right, but it will get you most of the way there. Include it in every ticket. Link to specific areas that apply to that ticket so engineers and testers know what to focus on. You can link right to the Deque chec...
    Read more

    Practice Site: Accessible Forms

    Image
    Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
    Read more