Day 78: Learning about Orca

Orca is an open source screen reader for Linux. This is my first time to read about it. Hopefully, I’ll have a chance to actually experiment using it. However, I’ll need to set up a Linux distribution that works with it first.

Things I accomplished

  • Attempted to install Orca on my netbook (Lubuntu), and then on my Raspberry Pi (Raspbian). Both failed attempts (today, anyway).
  • Read through a lot of Orca documentation.
  • Added keystrokes to my screen reader cheatsheet, and copied the spreadsheet over to my WAS cheatsheets on Google Sheets.

What I learned today

  • Orca can provide speech or braille output.
  • Orca is provided as a default screen reader for several Linux distributions, including Solaris, Fedora, and Ubuntu.
  • Orca provides a really cool feature called Where Am I that allows additional commands to inform the user about page title, link information (location, size), table details, and widget role and name.
  • Many of the navigation keystrokes are similar to other desktop screen reader commands.
  • Orca also has commands specific to dealing with Live Regions on webpages.
  • When the “Super” key is referenced, it’s talking about the Windows logo key.
  • Orca provides Gecko-specific navigation preferences. I wonder if it works best with Firefox?

Not only did I learn about Orca, but I also got sucked down the Linux rabbit hole in order to better grasp that OS, its distributions and desktop environments, and additional “universal access” for people with disabilities. However, that topic could take another week to work through.

Day 77: Experimenting with Window-Eyes

Window-Eyes is a screen reader that appears to have fallen out of the mainstream use. According to WebAIM’s latest Screen Reader Survey, 1.5% of their respondents reported that they use Window-Eyes. I experimented with it because it was listed as an example of an assistive technology to experiment and test out.

Things I accomplished

What I learned today

  • Window-Eyes works best with Internet Explorer.
  • Window-Eyes was folded into the AI Squared family, and there are instructions on how to migrate from Window-Eyes to JAWS (mp3).
  • Window-Eyes is free to download if you have a registered copy of Microsoft Office.
  • Most keystrokes are similar to other Windows screen readers, but uses Control or Insert keys as modifier keys.

Day 74: Striving for WCAG Level AAA, Part 3

Today I spent time with the Understandable Level AAA criteria. Some of the Readable Guideline’s success criteria (SC) seem like a nice effort to make for everyone who comes to your site. However, I can see how that can take a lot more communication between content creator and developer to provide the necessary additional content or appropriate code to implement sufficient techniques correctly.

Things I accomplished

  • Read Understandable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 7 Level AAA criteria under Understandable, none of which are new to 2.1:

  • 3.1.3 Unusual words
  • 3.1.4 Abbreviations
  • 3.1.5 Reading level
  • 3.1.6 Pronunciation
  • 3.2.5 Change on request
  • 3.3.5 Help
  • 3.3.6 Error prevention (all)

There are 0 Level AAA criteria under Robust.

Examples of Understandable Level AAA failures

SC 3.1.3 Unusual words Fail: Specialized words are used in the content, but no definitions are provided. Providing definitions or a glossary would greatly benefit people with cognitive, language, and learning disabilities.

SC 3.1.4 Abbreviations Fail: Abbreviations are present, but no expanded form is available on the page, in assumption that the user already knows what it means. This can create confusion for people with cognitive issues or those using a screen magnifier (which challenges contextual cues).

SC 3.1.5 Reading level Fail: No summary or additional visuals are provided for reading level below 8th grade. This may inhibit people with reading disabilities or English as a second language from understanding your content.

SC 3.1.6 Pronunciation Fail: No audio or text pronunciation is provided for difficult words. This hinders people who use screen readers and people with reading disabilities from fully understanding the content provided.

SC 3.2.5 Change on request Fail: A new window opens when the user clicks on a link without the user expecting the change of focus to a new window. Related to SC 3.2.1 and SC 3.2.2. This greatly affects people who use screen readers.

SC 3.3.5 Help Fail: A form supplies no detailed instructions about data format or additional information necessary to submit the form. Leaving out required information and helpful tips can hinder people with visual, cognitive, or motor disabilities form submitting the form correctly.

SC 3.3.6 Error prevention (all) Fail: A form that is not a legal, financial, or data transaction fails to provide a reversible, review, or confirmation step when error is possible. Related to SC 3.3.4. This may affect people with reading or motor disabilities.

Day 73: Striving for WCAG Level AAA, Part 2

Carrying on from Part 1, today I spent time with the Operable Level AAA criteria. There are a few, I feel, that should be on a lower conformance level, as well as best practice for web designers.

Things I accomplished

  • Read Operable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 12 Level AAA criteria under Operable:

  • 2.1.3 Keyboard (no exception)
  • 2.2.3 No timing
  • 2.2.4 Interruptions
  • 2.2.5 Re-authenticating
  • 2.2.6 Timeouts (new in 2.1)
  • 2.3.2 Three flashes
  • 2.3.3 Animation from interactions (new in 2.1)
  • 2.4.8 Location
  • 2.4.9 Link purpose (link only)
  • 2.4.10 Section headings
  • 2.5.5 Target size (new in 2.1)
  • 2.5.6 Concurrent input mechanisms (new in 2.1)

Examples of Operable Level AAA failures

SC 2.1.3 Keyboard (no exception) Fail: Div element has been scripted to be clickable, but is not identified as a link to assistive technology. This makes custom page navigation more difficult for people who use screen readers or voice input.

SC 2.2.3 No timing Fail: Web app forces a time limit on the user. This can make use of the web app harder for people with cognitive or motor impairments.

SC 2.2.4 Interruptions Fail: User is not given an option to delay or request non-emergency updates. Interruptions can be disorienting for a person who uses a screen reader when their cursor focus is forced elsewhere.

SC 2.2.5 Re-authenticating Fail: Form data is not saved when the user is timed out of a session. This can be frustrating for people who have motor or cognitive impairments.

SC 2.2.6 Timeouts (new in 2.1) Fail: Users are not explicitly warned about data loss due to inactivity time limits.

SC 2.3.2 Three flashes Fail: A video on the page contains three or more flashes in a 1-second period. This can greatly affect people who are prone to seizures.

SC 2.3.3 Animation from interactions (new in 2.1) Fail: Decorative animation that occurs when a user interacts with an element does not have a “reduce motion” option for users to turn it off. Animation can cause nausea for people with vestibular disorders and distraction for people with attention disorders.

Side note: This concept introduced me to the Reduced Motion media query. Before today, I didn’t know that existed!

SC 2.4.8 Location Fail: Users page location within that website is not evident. Breadcrumbs, sitemap, nor highlighted navigation bar has not been provided. This affects people with attention disabilities (as well as everyone else).

My two-cents: This seems like it should be good practice and common courtesy to help everyone find their way around your site. I had no idea it was Level AAA and have considered using breadcrumbs as part of business as usual when I build more pages for large sites.

SC 2.4.9 Link purpose (link only) Fail: Generic and unclear text is provided within hyperlinks. This can be confusing for people who use screen readers and voice input, as well as those with cognitive disabilities.

SC 2.4.10 Section headings Fail: Text-heavy content and instructions are provided on a page without any additional headings to segment sections of text for clarity. This greatly affects people with visual and cognitive disabilities.

Confession: This is a bit of a pet peeve of mine, and I often feel this should be part of best practice for web designers. It especially irritates me when I see lists nested within lists, but not headings are provided to chunk and clarify content areas that are text-rich. Please make your page more navigable for everyone by including section headings.

SC 2.5.5 Target size (new in 2.1) Fail: Interactive buttons and customized links are less than 44×44 pixels. This can make it especially hard for people with motor disabilities to activate the button or link.

Added note: this is already making its way into mobile web app best practice, which is where I was first introduced to this concept. I’m happy to see it considered as an accessibility issue, too.

SC 2.5.6 Concurrent input (new in 2.1) mechanisms Fail: Interactive components on a page restrict input from other input devices other than touch. Therefore, this restricts who uses that page because people of all abilities use their input device (or devices) of choice.

Day 72: Striving for WCAG Level AAA, Part 1

Originally, I thought I was going to do Level AAA conformance in one sitting. Turns out there were 28 additional criteria! To better digest the techniques and failures associated with these criteria, I had to break that reading up into three study sessions, given I spend approximately 1.5 hours a day studying. Not to mention, I find myself falling down a documentation rabbit hole to learn more about points I’m extremely curious about.

Things I accomplished

  • Read Perceivable’s Level AAA success criteria on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria.

What I learned today

There are 9 Level AAA criteria under Perceivable:

  • 1.2.6 Sign language (prerecorded)
  • 1.2.7 Extended audio (prerecorded)
  • 1.2.8 Media alternative (prerecorded)
  • 1.2.9 Audio-only (live)
  • 1.3.6 Identify purpose
  • 1.4.6 Contrast (enhanced)
  • 1.4.7 Low or no background audio
  • 1.4.8 Visual presentation
  • 1.4.9 Images of text (no exception)

Examples of Perceivable Level AAA failures

SC 1.2.6 Sign language (prerecorded) Fail: Sign language is not provided along with a prerecorded video. This SC benefits deaf who rely on American Sign Language as their first language.

SC 1.2.7 Extended audio (prerecorded) Fail: Movie moves to quickly to accommodate synchronized audio description. Video needs to be extended for substantial audio description. This SC enables blind and visually impaired to better understand what the movie is conveying.

SC 1.2.8 Media alternative (prerecorded) Fail: Full text transcripts of equal experience for a prerecorded video are not provided  This SC benefits people who have a combination of visual and auditory impairments.

Confession: I often confuse captions and transcripts. They are not the same and do not provide the same access to everyone. Ultimately, captions are the bare minimum. Transcripts are more inclusive.

SC 1.2.9 Audio-only (live) Fail: No text alternative, like live captioning, was offered during a live audio performance. This would benefit people with auditory

SC 1.3.6 Identify purpose Fail: Landmarks are not identified across the page. This inhibits the adaptability of the page to meet the needs of those with cognitive disabilities. Related to SC 4.2.1.

SC 1.4.6 Contrast (enhanced) Fail: Contrast of foreground text/images over background does not meet the 7:1 ratio. This enhanced criterion makes it easier for people with low vision or colorblindness to perceive content. Related to SC 1.4.3.

SC 1.4.7 Low or no background audio Fail: An audio track that is embedded on the page that contains a speech with background music doesn’t offer the user the ability to turn off the background music. This criterion is meant to enhance the distinguishability of that speech for people who are hard of hearing.

SC 1.4.8 Visual presentation Fail: Paragraph text is justified. This presents reading challenges to those with reading, cognitive, or visual disabilities.

Confession: I strongly feel that SC 1.4.8 could easily be pushed into Level AA, so more people would strive for better visual presentation for all users, since it strikes me as just good practice and even common courtesy for everyone. I mean, who doesn’t benefit from left-aligned text, greater line spacing, shorter paragraph width, a choice or foreground/background colors, and elimination of horizontal scrolling of text??

SC 1.4.9 Images of text (no exception) Fail: Images of text (not including the brand logo) are present throughout the site. People who zoom or magnify their screen would benefit greatly from the elimination of all images with text. Related to SC 1.4.5.

Off topic but interesting

Today I learned that there are over 120 HTML elements from 4.01 on up to 5.2. Then there are all those attributes to go along with them. This huge inventory just confirms to me that more developers should spend more time with the “basics” of HTML. Some parts of Level AAA could be more achievable (i.e. SC 1.3.6) if people spent more time understanding the building blocks, along with CSS, rather than focusing on the “perfection” of JavaScript and other programming languages to get the front-end job done.

Day 71: How to Fail WCAG Level AA, Part 2

Continuing on from Part 1 with how to pass or fail WCAG Level AA…

Things I accomplished

  • Read Operable, Understandable, and Robust success criteria (Level AA) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are only 3 additional operable success criteria:

  • 2.4.5 Multiple ways
  • 2.4.6 Headings and labels
  • 2.4.7 Focus visible

There are only 5 additional understandable success criteria:

  • 3.1.2 Language of Parts
  • 3.2.3 Consistent navigation
  • 3.2.4 Consistent identification
  • 3.3.3 Error suggestion
  • 3.3.4 Error prevention (legal, financial, data)

There is only 1 additional robust success criterion, which was added in 2.1:

  • 4.1.3 Status messages (new to 2.1)

Examples that fail base conformance

Operable

SC 2.4.5 Multiple ways Fail: Not enough options to explore the website for people who have visual or cognitive disabilities. Provide alternative ways to navigate via search, sitemap, or table of contents.

SC 2.4.6 Headings and labels Fail: No section titles have been provided for a text/content-heavy page. This eases navigation for people with visual, motor, and cognitive impairments (and everyone else).

SC 2.4.7 Focus visible Fail: Focus outline was removed for input controls. This impacts keyboard-only users who need to see their navigation points throughout the page.

Understandable

SC 3.1.2 Language of Parts Fail: Paragraph and span elements do not contain a lang attribute when a change of language is obviously present. This impacts understanding for anyone, but especially impacts screen reader users and browsers that need explicit identification of document and parts of text language. Related to SC 3.1.1.

SC 3.2.3 Consistent navigation Fail: Global navigation links are not consistent in presentation and order across the website. This can be confusing for anyone, but especially impacts people with cognitive impairments.

SC 3.2.4 Consistent identification Fail: Components with the same function are not consistently labelled across the website, which impairs recognition of similar tasks and functionality. Related to SC 1.1.1 and SC 4.1.2. This can affect people with visual or cognitive impairments.

SC 3.3.3 Error suggestion Fail: No description of required input error is provided client-side nor server-side. Related to SC 3.3.1 and SC 3.3.2. This can affect people with visual or cognitive impairments.

SC 3.3.4 Error prevention (legal, financial, data) Fail: During an online data transaction, the user is not given an opportunity to review, correct, or reverse the form data being submitted. Especially on multi-step forms that requires a few pages, this can affect people with cognitive disabilities.

Robust

SC 4.1.3 Status messages (new to 2.1) Fail: A role=”status” was not assigned to a search update that returned x-amount of results. Role needs to be assigned to the status update of how many results found. This can greatly impact visually impaired who use screen readers.

You can quickly find what you need

Last night (in bed, of course), I was thinking about how the WCAG Quick Reference could use some filtering options, like tags, in order to quicken my information discovery. Well, someone was already thinking of this! They have many filters, including WCAG version, tags, conformance levels, techniques, and technologies, set up to help people find what they’re looking for:

Filter tab open revealing options like version, tags, levels, and techniques.

I should have explored this option earlier in my week!

In conclusion

9 more success criteria across three principles is not too much more to ask of designers and developers. To reinforce that idea, I don’t find these nine criteria especially hard to implement.

 

Day 70: How to Fail WCAG Level AA, Part 1

The last three days I’ve reviewed failures for WCAG Level A within Perceivable, Operable, and Understandable and Robust. Now it’s time to step up our expectations and look out how we’re all fairing at the middle conformance level: Level AA.

Things I accomplished

  • Read through Perceivable success criteria (Level AA) techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures.

What I learned today

Within the Perceivable principle, there are 11 additional success criteria to meet Level AA conformance within the latest WCAG recommendation (2.1).

5 SC within WCAG 2.0:

  • 1.2.4 Captions (live)
  • 1.2.5 Audio descriptions (pre-recorded)
  • 1.4.3 Contrast (minimum)
  • 1.4.4 Resize text
  • 1.4.5 Images of text

6 more SC added in WCAG 2.1:

  • 1.3.4 Orientation (new to 2.1)
  • 1.3.5 Identify input purposes (new to 2.1)
  • 1.4.10 Reflow (new to 2.1)
  • 1.4.11 Non-text contrast (new to 2.1)
  • 1.4.12 Text spacing (new to 2.1)
  • 1.4.13 Content on hover or focus (new to 2.1)

Examples that fail base conformance

SC 1.2.4 Captions (live):  In Level A, pre-recorded video with audio required captions. Level AA conformance fails when no open/closed or synchronized text stream is provided with captioning during live synchronized video with audio. This affects people with hearing impairments.

SC 1.2.5 Audio descriptions (pre-recorded): In Level A some sort of alternative (AD or text) needs to be provided for videos. Level AA conformance fails when there is no audio description track provided. This presents a challenge to users who may not be able to see the video.

SC 1.3.4 Orientation (new to 2.1): The user is prevented from using landscape view within a web app that does not essentially need to remain in portrait view. This affects people who magnify the screen and choose to view webpages in landscape.

SC 1.3.5 Identify input purposes (new to 2.1): No input data type or instructions for restricted data input are conveyed to the user. This affects people who use screen readers and some people with cognitive disabilities.

SC 1.4.3 Contrast (minimum): Background color and foreground text color have a contrast ratio of under 4:5:1 which makes it hard for people with visual impairments to perceive.

SC 1.4.4 Resize text: When text is resized within the browser at 200%, text is clipped. This makes reading your text difficult for people with visual impairments.

SC 1.4.5 Images of text: An image with text was used, even though it could have been presented in the same way with true text and use of CSS. This greatly affects people who magnify or zoom into their screen and the image pixelates.

SC 1.4.10 Reflow (new to 2.1): Media queries are absent. Content forces user to scroll horizontally and vertically. This presents a challenge to people who need to enlarge text or zoom into the screen.

SC 1.4.11 Non-text contrast (new to 2.1): Low contrast between text box and its background. No border is present. Like SC 1.4.3, this affects anyone with a visual impairment, including colorblindness.

SC 1.4.12 Text spacing (new to 2.1): Content boxes are restrictive in size and don’t allow for text spacing to be adjusted by the user without text being clipped. This greatly affects people with visual impairments, dyslexia, and cognitive disabilities.

SC 1.4.13 Content on hover or focus (new to 2.1): Custom tooltip is not persistent nor dismissable. This greatly affects people who magnify their screen.

In conclusion

I had to cut the list of Level AA SC in half since there are 20 additional criteria, in total. I’m feeling a little more confident about my organizations efforts to achieve Level AA, and am happy to see that other people are paying attention to color contrast and reflow issues. Pertaining to the Perceivable principle, I don’t think it takes to much effort to step up a level to remove even more barriers for people of all abilities.

Day 69: How to Fail the Bare Minimum of Understandable and Robust

Today I’m concluding Level A conformance evaluation, looking at the Understandable and Robust principles of WCAG.

Things I accomplished

  • Read Understandable and Robust success criteria (Level A) failure techniques on How to Meet WCAG 2 site.
  • Mapped success criteria to failures of those criteria that I’ve encountered or read about.

What I learned today

There are 5 bare minimum (Level A) success criteria recommended by W3C in order for websites to be understandable (readable, predictable). These success criteria are, as follows:

  • 3.1.1 Language of Page
  • 3.2.1 On focus
  • 3.2.2 On input
  • 3.3.1 Error identification
  • 3.3.2 Labels or instructions

There are 2 bare minimum (Level A) success criteria recommended by W3C in order for websites to be robust (compatible for assistive tech and adaptive strategies). These success criteria are, as follows:

  • 4.1.1 Parsing
  • 4.1.2 Name, role, value

When these seven success criteria are met, it enables people of different abilities, no matter what aids they use, to understand and continue using your online content and services.

Examples that fail base conformance

SC 3.1.1 Fail:  A lang attribute is not present on the html element. The language of the web document needs to be explicitly defined for screen readers and browsers.

SC 3.2.1 Fail: Link opens a new tab. This should be avoided if not critical for the user because it can be disorienting to people of all abilities. I still see this a LOT for links, in particular, where no alternative of additional warning text is provided.

SC 3.2.2 Fail:  Form submitted ‘onchange’ rather than allowing the user to submit the form when they were actually done. This impairs people from completing forms accurately and at their own pace.

SC 3.3.1 Fail: No descriptive error text was provided for required fields to help user know why their form was unable to submit.

SC 3.3.2 Fail: No label was associated with an input control by using ‘for’ and ‘id’.

SC 4.1.1 Fail: I’ve recently run across a few of these failures! They usually come down to typos. For instance, if quotes or brackets aren’t closed, or no space is left between attributes, it can create an incomplete picture for assistive technologies and browsers.

SC 4.1.2 Fail: No role, name, or state were provided on a custom component control with a div or span.

In conclusion

Though this evaluation was shorter, I recognized several things I knew to cause accessibility problems, but I didn’t realize how bare minimum they were in this specification and how long they’ve been around (none are new in 2.1). I would be bold enough to say that all of these are easy failures to avoid and come at no real cost to the developer who knows what she’s doing. Now, if you’ll excuse me, I have a few bare minimum things to fix in my code this week…

Tomorrow I’ll start looking at the next level up, which is a common goal for many organizations, including my own. I’ll find out if we’re meeting that goal or not!

Day 65: Identifying A11y Issues for Switch Control Users

About a week ago I learned more about users with motoric disabilities, which is usually who I think of when it comes to switch device use. Today I wanted to focus more on what challenges switch device users may encounter when using websites. My study time ended up turning into review of some things I’d already learned, as well as discovering some new articles and videos about switch access.

I was not able to do any testing myself, since I don’t have any switch devices. On another day, when I’m feeling more adventurous, I’ll dedicate a study session to testing with a Bluetooth keyboard or Android device buttons to simulate the experience.

Things I accomplished

What I learned today

Apple’s Switch Control feature is built over the VoiceOver platform, so that’s how it knows to recognize things like buttons. Point mode allows access to otherwise inaccessible apps by scanning horizontally and vertically (x, y coordinates) to create clickable point. It also gives an alternative for quicker access to focuable elements on a web page, rather than waiting for a page to be parsed and scanned piece by piece.

After learning more about switches and switch control, I can better understand the many switch control settings on my iPhone.

I usually think of switches being used by people with motor disabilities, but there are other people who use it, too. Some people with intellectual or learning disabilities may use a switch because a mouse, keyboard, or game controller is just too complex to use.

Switch access includes devices that can receive input from almost any body part. Actions may include, but are not limited to:

  • sip-puff
  • push
  • pull
  • press
  • blink
  • squeeze
  • twitch

Windows 10 has eye control as a method of switch access. Apple doesn’t have this feature… yet.

Android mobile devices have switch access much like Apple’s feature.

In review of what I learned last week

Restating from my article mentioned at the beginning, designers and developers need to review WCAG’s operable principle for switch control accessibility. It can’t be emphasized enough that if your website is following those guidelines and success criteria, your website will be accessible to switch users and many other users.

What front-end developers can do for switch control users:

  • make the website keyboard accessible so all elements are reachable
  • place key elements above the fold to relieve tedious scrolling
  • allow alternative to advanced gestures, like hover over and drag-and-drop
  • use larger text for readability from a further distance of user between screen
  • avoid time limits or allow user to increase time limit
  • tolerates user error
  • provide alternative navigation methods to skip over lists of links, repetitive sections, and lengthy text
  • offer autocomplete, autofill, or autosave
  • manage off-screen items appropriately (display:none, visibility:hidden when out of view)
  • provide clear focus outlines

 

 

Day 63: Practice with JAWS

Back to playing with assistive technology. I wanted to mess around with speech input software, but I started the process and realized that will be a weekend project, due to the learning curve. So I settled on working in JAWS today to continue learning assistive technologies and what experience they provide.

Note: JAWS is really robust and considered top-notch in the screen reader industry. By no means, am I an expert at using JAWS. However, I need more practice with it, since I lean more heavily on NVDA for screen reader testing.

Things I accomplished

What I learned today

JAWS stands for “Job Access With Speech”.

The cursor on the screen blinks REALLY fast when JAWS has been activated.

Some of JAWS basic keyboard commands are very similar to NVDA’s (or vice versa). That was extremely helpful when experimenting with it. That made me happy when thinking about one of my blind friends that recently made the switch from JAWS to NVDA. It likely made her transition a whole lot easier! (now I’ll have to ask her about it)

I used Insert + F3 a lot to move more quickly through a page’s regions and interactive areas. I liked how many options I had on their built-in navigation feature. However, I did accidentally discover a browser difference with Virtual HTML Feature when I switched over to my Firefox window to add notes to this post (colors are funny because my system was in High Contrast Mode at that time).

Firefox with Insert + F3:

JAWS Find dialog window.

IE with Insert + F3:

Virtual HTML Features dialog.

The built in PDF reader in IE didn’t seem to register any regions with the Deque cheatsheet, like NVDA with Firefox did. So I couldn’t quickly navigate between tables within the browser.

I really like how I could sort links by visited, unvisited, tab order or alphabetically! Plus, I could either go to link or activate the link as soon as I found it in this list.

JAWS Links List dialog.

JAWS had a few more customization choices than NVDA:

JAWS Settings Center dialog.

My bad: I inadvertently found a few photos on a site I manage that needs some alternative text because they are not decorative.