In Virtual PC mode JAWS does not support aria-describedby for listboxes without a focus

Summary

JAWS does not emit descriptions of elements with "listbox" ARIA role. The descriptions are provided via aria-describedby attribute. Reproducible when listboxes does not have focus.

Rename an extension of the attached sample file from .txt to .html, open the sample in Chrome. odan_397_descriptions.txt The sample file has 2 listboxes. The first one is with an accessible label only; The Second listbox has an accessible label and description
Set PC focus to the first edit field.
Switch JAWS to the Virtual PC Cursor mode (numpad-plus)
Press Down Arrow key multiple times to see what is exposed to screen reader

--- JAWS transcript in Virtual Cursor begins ---

The First Registry List box The Second Registry List box --- the end ---

--- end of JAWS transcript ---

The bug: The "The Second Registry" listbox has an accessible description provided through aria-describedby attribute, but this description is not emitted by JAWS. The bug is reproducible with the Default JAWS settings (Insert-Space, z) It is not possible to configure JAWS to get the descriptions. Even following settings in JAWS Speech and Sound Schema config file does not help: [HTML Attribute Behavior Table] describedby=1|Zoe80:Use JawsKey+Alt+R to read descriptive text||| longdesc=1|Zoe60:Press Alt+Enter for Long Description|| [Other Behavior Table] Description=3|MessageVoice||Daniel60|

Expected result

The following JAWS transcript is expected: --- Expected JAWS transcript for the Second listbox ---

The Second Registry List box An accessible description

--- end of JAWS transcript ---

in this expected transcript, the description is emitted.

Additional Information

The bug is reproducible with the default JAWS settings (Insert-Space, z) The bug is reproducible in JAWS 2023 August release. The bug is reproducible with JAWS 2024 beta September release.

JAWS version and build number

JAWS version 2023.2307.37.400 JAWS version 2024.2308.124.400

Operating System and version

Microsoft Windows 10 Professional Version 22H2 (OS Build 19045.3448), System Type x64

Browser and version:

Google Chrome Version 116.0.5845.188

In my opinion, this is not a bug, but standard JAWS behaviour for all elements. In VPC mode, descriptions are never output, only labels. In forms mode, descriptions are output by default.

It could be a feature request that there is an option in the settings that descriptions are also output in VPC mode.

Hello, friends, Thank you for helping to survive in this inaccessible world,

The first inconsistency

In my opinion, this is not a bug, but standard JAWS behaviour for all elements.

Not for all elements.

Please, rename the extension of this sample file from .txt to .html and open it in Chrome. odan_397_github_761_descriptions.txt

Use Virtual Cursor mode and down arrow key to get the following JAWS transcript:

--- JAWS transcript --- // Down arrow key pressed The second listbox has an accessible description. // Down arrow key pressed An accessible label check box not checked an accessible description --- end of JAWS transcript ---

AS you can see, JAWS supports descriptions for checkboxes, but does not supports for listboxes. So this is the first inconsistency.

Second inconsistancy

Use quick navigation key "f" in Virtual PC Cursor mode. In Virtual PC Cursor mode, With the "f" quick nav key both the descriptions are accessible (for the checkbox and for the listbox). Thus, we have the second inconsistancy with JAWS: sometimes descriptions are accessible, sometimes are not.

3rd inconsistancy

In the Virtual PC Cursor mode, blind users can navigate to the listbox and press Insert-Alt-r to get the description. Try it with the attached sample files - this functionality works. But JAWS users are not notified that ther is a description availabel while navigating using down arrow keys.

Thus, web page authors provides descriptions, JAWS sees the descriptions, but blind users do not see the fact of the description availability.

Inconsistency: users can press Insert-Alt-r on all elements, sometimes they get the description, sometimes they does not get a description. Not possible to distinguish which element have and which does not have a description.

Blind users are not independent when use JAWS

The goal of the accessible description is to explain something to blind users.

According to ARIA, accessible labels must be short strings (1-3 words), and accessible descriptions can be long.

So assistive technologies emit a label, a control type and finally the description. This approach allows quickly navigate for those blind users who is familiar with the interface: they quickly get the short label and short control type - no need to listen the description. But those who just learn the page, they wait for the label, the control type and for the full description which is not emitted by JAWS, and the fact of availabel description is also not emitted by JAWS.

You may say - the description is accessible using Quick Navigation keys. But blind users press quick navigation keys when they are familiar with the interface and would like to jump quickly to elements which they know about.

Another use case of the Virtual PC Cursor for blind users is to learn the interface. There is only two options:

Someone teaches the blind user about shortcuts and quick jumps, in this case blind users are not independent. Sighted users are independent, but blind users are not.
Blind users use dow arrow key inside a page section to see the full content of the page section. And in this second case, the blind people are independent, because they could learn the page independently. They could literally see what is shown for sighted users.

But JAWS does not support independence of blind users, they always need someone's help because JAWS does not emit descriptions in the case when people are learning the page content. There is only one mode allows to see everything what is shown for sighted people: this is the Virtual PC Cursor and the down arro key. But in this case JAWS does not emit descriptions. This is where the descriptions is mostly needed: When blind users first time learn the page.

ARIA Violation

By ignoring accessible description JAWS violates ARIA.

ARIA: What ARE Accessible Names and Descriptions?

https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/#names_and_descriptions_definition

An accessible name is a short string, typically 1 to 3 words... An accessible description is also an author-provided string that is rendered by assistive technologies... Assistive technologies present names differently from descriptions. For instance, screen readers typically announce the name and role of an element first. If an element has a state, it could be announced either before or after the name and role... Because descriptions are optional strings that are usually significantly longer than names, they are presented last, sometimes after a slight delay.... To reduce verbosity, some screen readers do not announce descriptions by default but instead inform users of their presence so that users can press a key that will announce the description.

Thus, JAWS violates the following in ARIA:

An accessible description ... is rendered by assistive technologies... To reduce verbosity, some screen readers do not announce descriptions by default but instead inform users of their presence so that users can press a key that will announce the description.

Currently, in Virtual PC Cursor mode with down arrow key reading:

JAWS does not emit the description
JAWS does not emit the availability of the description

According to ARIA, JAWS must to one of these: emit the description or inform users about the description availability.

I was able to reproduce the first inconsistency: The checkbox is also output in VPC mode with a description. However, this seems to me to be the exception - perhaps this should be fixed.

I think that descriptions usually contain operating instructions and when I read in VPC mode, I am more concerned with the content and not the operation. That's why I think it's good that the descriptions are not output in VPC mode.

For this reason, I don't find your 2 inconsistency problematic: When I navigate to the controls with F, it's similar to TAB navigation in forms mode: I want to reach and operate controls and thus also hear the operating instructions.

I think there should be a setting option in the speech verbosity that makes it possible to output the operating instructions also in VPC mode. This is especially important if there are descriptions on non-control elements, e.g. a div element with title attribute.

In complex web applications with multiple interactive widgets, form elements and plain text in between, users cannot start using quick navigation keys or tab keys, users must see first what is exposed visually. There is only one option to do this: Using landmarks or headers, navigate to the desired page section, use down arrow multiple times to see what is inside the section. You know, JAWS recommends for experienced users to use Forms Mode to be set to "Manual" while "Auto" is intended for beginners.

How descriptions works according to ARIA (and sometimes in JAWS)

Descriptions are emitted after the label and the control type. This is why the labels are always short and descriptions can be long. Thus, when users navigate using down arrow, they listen the label first, then the control type. Both the label and the control type are very short strings. In case if users do not want to listen the long description, they just press a key and description is interrupted and new element starts. Thus, for those who is familiar with the description, or do not want to know too much about the element, they do not suffer, they just move to the next element which they would like to perceive. But those who learn the complex web application interface, who need all details, need more explanations, they can continue to listen to perceive the description.

Checkbox and descriptions

Use case: A complex widget showing a table. Table can be filtered. Number of filters not limited. Each filter can be temporarily enabled and disabled through checkboxes. All filters included into a landmark "Report Filters" Inside this landmark we have multiple checkboxes, plain text showing additional information, edit and delete buttons to edit or remove the filter. Using down arrow users see the checkbox. Is this checkbox belongs to previous filter or to the next filter? How to understand? The accessible description is currently available and supported by JAWS. When you say "to be fixed". Do you mean that description should be removed from checkboxes as well? O no.

As for "descriptions usually contain operating instructions ". This is too narrow usage of descriptions. When we teach someone how to use an element, we add something about this element. Instead of teaching every user, we can add the accessible description. For example, descriptions for list box can provide the following: "Presented in 5 rows and 10 columns". ARIA has aria-orientation=undefined for cases when listbox not oriented vertically or horizontally, but the description helps to understand how the listbox is shown visually. Another use case. Let say you have button "Edit". What this button does? Open a new web page with some functionality to edit something? Description says: "Interactive Grid is in the View mode, press to switch to Edit mode". Can it be helpful?

Negative side effect of this issue

Accessibility developers need to explain something to blind users through screen reader interface. Descriptions does not work. Tab stop jumps ignoring elements without tab stop (for example, any plain text is ignored). So, the only way to provide an explanation is to include all descriptions into accessible labels. And we do observe it over Internet. Some accessible labels become 20 words. As a blind user, I forced to listen 20 words before I get the control type of the element. What does it mean for me? I must listen every plain text till the end. What if this is not a plain text but some control element with the very long label? So, this issue leads to violation of ARIA recommendations for friendly accessible names. Developers of accessible interfaces forced to create long labels, making blind users less effective they their sighted colleagues.

FreedomScientific / standards-support