NVDA and How Buttons Are Announced


Marc Grossman
 

I am testing a modal dialogue with NVDA/Firefox, Jaws/Edge, and VoiceOver/Safari on a desktop platform. The modal is launched with a form control (button). Screen reader encounters three form controls (buttons) on the modal.
 
NVDA:
Using TAB and the shortcut key B navigate screen reader focus and announce as Label/Control type, e.g. "Close Button"
Using arrow keys, screen readers announce Control Type/Label, e.g. "Button Close"
 
Jaws/Edge:
Using TAB, the shortcut key B, and arrow keys all navigate screen reader focus and announce as Label/Control type, e.g. "Close Button"
 
VoiceOver/Safari:
Using both TAB and VO+arrow keys, the screen reader announces Label/Control Type, e.g. "Close Button"
 
I understand that this might actually be the expected behaviour. Can anybody point me to resources on the web that confirm this?
 
Thanks in advance for any assistance. 


Chris Smart
 

 

I understand that this might actually be the expected behaviour. Can anybody point me to resources on the web that confirm this?

 

 

What do you mean by “actually be”?

How do you think the screenreader should identify the control type and function?

 

Are you a blind person who uses a screenreader regularly, or a sighted person who doesn’t rely on the screenreader feedback?

 

Are you familiar with WCAG "Success Criteria"?

If so, these may be related to your situation.

1.3.1: Info and Relationships.

2.4.6: Headings and Labels.

3.3.2: Labels or Instructions

4.1.2: Name, Role and Value


Carlos Medrano
 

Hi Marc,

from the perspective of someone who uses NVDA daily, everything you described is expected behavior.


I'm not an expert on web certifications, but have you looked into the Web Content Accessibility Guidelines [0]? For example, section 4.1.2 [1] describes the need for UI components to have a name, role, and value that can be determined and set programmatically. Also, section 2.1.2 [2] may also be of interest to you, which describes keyboard traps, such as those caused by embedded applications/modals and the need of having a convenient way of jumping out of them with a keyboard or with a button.


Note that it may be worth testing each screen reader with each of the browsers; some browsers may give different behaviors with different screen readers. For example, the Free PBX [3] web GUI works better with Firefox and NVDA; Chrome does not show all the controls on the page.

Hope this is helpful.

Best,

Carlos


[0]: https://www.w3.org/TR/WCAG21/

[1]: https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

[2]: https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap.html

[3]: https://www.freepbx.org/


On 5/18/2022 10:01 AM, Marc Grossman wrote:
I am testing a modal dialogue with NVDA/Firefox, Jaws/Edge, and VoiceOver/Safari on a desktop platform. The modal is launched with a form control (button). Screen reader encounters three form controls (buttons) on the modal.
 
NVDA:
Using TAB and the shortcut key B navigate screen reader focus and announce as Label/Control type, e.g. "Close Button"
Using arrow keys, screen readers announce Control Type/Label, e.g. "Button Close"
 
Jaws/Edge:
Using TAB, the shortcut key B, and arrow keys all navigate screen reader focus and announce as Label/Control type, e.g. "Close Button"
 
VoiceOver/Safari:
Using both TAB and VO+arrow keys, the screen reader announces Label/Control Type, e.g. "Close Button"
 
I understand that this might actually be the expected behaviour. Can anybody point me to resources on the web that confirm this?
 
Thanks in advance for any assistance. 


Chris Smart
 

Hi Carlos.

 

Do you do Website accessibility testing and remediation work?

 

I am just getting started in that field, so I hope I didn’t lead Mark astray with my suggestions. It sounds like you have a better handle on WCAG than I do at this point. 😁

 


Carlos Medrano
 

Hi Chris,

Thanks, but I don't. WCAG is usually fresh in my mind because people I know run web accessibility-related questions passed me every once and a while. :-)


On 5/18/2022 10:58 AM, Chris Smart wrote:

Hi Carlos.

 

Do you do Website accessibility testing and remediation work?

 

I am just getting started in that field, so I hope I didn’t lead Mark astray with my suggestions. It sounds like you have a better handle on WCAG than I do at this point. 😁

 


Marc Grossman
 

Yes I am a daily screen reader user and am familiar with WCAG. I wholeheartedly agree with both of you that form controls should announce the type of control, the state of the control, and the label on the control. Your references to WCAG guidelines are spot on.

My main question can be boiled down to this. If I navigate with arrow keys to the control, it is announced by NVDA as "Button Close" but If I navigate to the control with the tab key or the letter B, NVDA announces as "Close Button."

 

The engineer has informed me that it was coded to meet WCAG guidelines and another colleague believes that this is the expected behavior. I do not like to necessarily make comparisons to other assistive tech but in this case I do think it is relevant. Jaws and VoiceOver both announce the control as "Close Button" regardless of how focus is navigated to the control.

Was just wondering if that sounds correct? If so, is there any documentation to inform others on how NVDA handles form controls, specifically buttons.

Thanks


Gene
 

But you are still getting all the information.  I haven't compared other screen-readers but I believe this is expected behavior in NVDA.  JAWS allows you to set whether you hear the kind of control before other information or other information first.  It is not determined by the web page. 

IN NVDA, if I tab to a link that is visited, I hear the link spoken before visited.  If I up or down arrow to a visited link, I hear visited link before the link is spoken.

In other words, these variations are screen-reader variations and aren't determined by the web page.

Gene

On 5/18/2022 2:16 PM, Marc Grossman wrote:

Yes I am a daily screen reader user and am familiar with WCAG. I wholeheartedly agree with both of you that form controls should announce the type of control, the state of the control, and the label on the control. Your references to WCAG guidelines are spot on.

My main question can be boiled down to this. If I navigate with arrow keys to the control, it is announced by NVDA as "Button Close" but If I navigate to the control with the tab key or the letter B, NVDA announces as "Close Button."

 

The engineer has informed me that it was coded to meet WCAG guidelines and another colleague believes that this is the expected behavior. I do not like to necessarily make comparisons to other assistive tech but in this case I do think it is relevant. Jaws and VoiceOver both announce the control as "Close Button" regardless of how focus is navigated to the control.

Was just wondering if that sounds correct? If so, is there any documentation to inform others on how NVDA handles form controls, specifically buttons.

Thanks



 

Hi all,

Specifically, the answer lies with how NVDA treats text information (and formatting) as you navigate by character/word/line. While I can't go into details without risking finals study schedule, all I can say (at this time) is that NVDA will look at formatting information as you use arrow keys to navigate text in browse mode context. The reason why you hear "close button" when you press Tab key versus "button close" as you press arrow keys has to do with the fact that the former responds to possible system focus changes and the latter is a reaction to browse mode cursor location changes.

In answer to the big question posed: this is screen reader specific. You can in fact tell JAWS to announce control type (that's what it is called) before label, and NVDA does so differently based on context you are in. I can go into details upon request (either next week or in July).

Cheers,

Joseph


Carlos Medrano
 

This is strictly anecdotal from personal observation, but I've grown to associate focus vs brows mode based on the way controls are spoken. For example, brows mode usually prepends the control type before the name for most things like buttons and links. As far as I'm aware, the screen reader chooses how to present that data, not the web developer.


It's been a while since I used JAWS, but I remember it behaving similarly when navigating using NVDA's equivalent of brows mode VS just tabbing around in it's focus mode equivalent.


On 5/18/2022 12:28 PM, Gene wrote:
But you are still getting all the information.  I haven't compared other screen-readers but I believe this is expected behavior in NVDA.  JAWS allows you to set whether you hear the kind of control before other information or other information first.  It is not determined by the web page. 

IN NVDA, if I tab to a link that is visited, I hear the link spoken before visited.  If I up or down arrow to a visited link, I hear visited link before the link is spoken.

In other words, these variations are screen-reader variations and aren't determined by the web page.

Gene

On 5/18/2022 2:16 PM, Marc Grossman wrote:

Yes I am a daily screen reader user and am familiar with WCAG. I wholeheartedly agree with both of you that form controls should announce the type of control, the state of the control, and the label on the control. Your references to WCAG guidelines are spot on.

My main question can be boiled down to this. If I navigate with arrow keys to the control, it is announced by NVDA as "Button Close" but If I navigate to the control with the tab key or the letter B, NVDA announces as "Close Button."

 

The engineer has informed me that it was coded to meet WCAG guidelines and another colleague believes that this is the expected behavior. I do not like to necessarily make comparisons to other assistive tech but in this case I do think it is relevant. Jaws and VoiceOver both announce the control as "Close Button" regardless of how focus is navigated to the control.

Was just wondering if that sounds correct? If so, is there any documentation to inform others on how NVDA handles form controls, specifically buttons.

Thanks