JAWS does not emit descriptions in VPC

[Vladimir-Goncharov-a11y]

### Summary
JAWS has Virtual PC Cursor mode, which allows blind people to see the visual interface.
Blind users perceive the following information about elements:
* label
* Control Type
* ARIA Attributes
* Descriptions

JAWS has only one method for blind users to see/perceive all elements in a section of the page: This is down arrow key in virtual PC cursor. 

There are more other methods, like Quick Navigation Keys, when users already familiar with the page and knows what is there and  where to jump to. Or, even Tab key in Forms mode.
All other methods does not allows to see/perceive all accessible information  on the page because  such methods use jumps skipping other elements. 

Thus, only Down Arrow key in VPC allows blind people to see  all accessible elements on the page.

The problem is that JAWS does not emit descriptions as one of following:
* The description itself
* The fact that this elements has a description

ARIA about accessible names and descriptions says:
https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/
Under section: What ARE Accessible Names and Descriptions?
"An accessible name is a short string, typically 1 to 3 words...
An accessible name serves two primary purposes...:


* Convey the purpose or intent of the element.
* Distinguish the element from other elements on the page.
...
An accessible description is ...a string that is rendered by assistive technologies. 
Assistive technologies present names differently from descriptions. ..., screen readers typically announce the name and role of an element first, ... Because descriptions are optional strings that are usually significantly longer than names, they are presented last, ...
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."

#### ARIA violation by JAWS
In the mode, where user expects to see the full details of the page, JAWS does not emit a description, and JAWS does not emit the fact that the description is present.
Moreover, it is not possible to configure JAWS to emit descriptions in VPC.

### This bug leads to additional ARIA violation
Accessibility developers, when need to provide additional information to an element, they cannot use accessible description because they are literally not accessible.
As a result, all accessibility developers are forced to squeeze  additional information to labels of elements.
By doing this they violates the ARIA rule for accessible  names, saying that the accessible name is a short string, typically 1-3 words.
Also, they violates the primary purpose of accessible names: convey the purpose, distinguish from other elements (see quote above).   because the add the states or properties of an element to the labels, instead of descriptions.

### Use cases
We have an accessible development environment. When a developer runs a developed application, she/he can see a developer section on a page with a control elements, such us:
Label: session, Type: Button menu
Label: Debug, Type: Button menu

There are multiple various options of those button menus.
For example, for Session we can override the application Language and can change it to German, Or, we can override a default date format.
How then  JAWS users can see if the session has overrides or not?
According to ARIA, we should use aria-description/aria-describedby  pointing to a text like "Language german, Date Format DD-mon-yyyy".
But then JAWS ignores the descriptions when the blind developer reviews the section with all dev controls.
As a result, as accessibility developers, we should add this information to the label, making the label to be long, and JAWS output become like this:
> Session, Language German, Date Format  // the long label
> Button menu // The control type



But, with  working descriptions we would have something like:
expected JAWS transcript
> Session // The concise label
> Button menu // The control type
> Language German, Date format DD-Mon-YYY // the long description

Now, when users use the Down Arrow to see what are available options, when label is long, a user is forced to listen the long session label including the current session status.
User  is forced to listen the full session status even when he/she do not need it, because, he/she needs a control type first, to understand what is the type of an element the VPC focus is placed on.

But when descriptions  are accessible, users can press down arrow, listen "sesstion" as a short label, percieve "Button menu" as a control type, After that they can decide, if they need the currect session state this time, they can continue listening, if the do not need a description, they press Down Arrowmoving to the next element, which is debug menu button.

With the same applied to the Debug Button menu, w which we currently forced to add long label like "Debug, current debug level  colon  7".
But what if blind user do not need session or debug, but looking for something else in the section?
With long labels and no descriptions (as not supported by JAWS), the blind developer will be slow. While with  short labels, the same  blind developer would be much faster.

This leads further
Who need to hire blind slow developers? As a result, sighted developers are hired for accessibility work, which leads to even worse result, which we (those who blind) see on the Internet.

Do you see how severe this bug is? :-)

### JAWS version
All versions, including JAWS 2044 July public release.

### Working use case with  checkboxes in JAWS
Nevertheless, JAWS supports descriptions for   checkboxes, thus when we  need to expose accessible settings for an complex widgets like Interactive Report component, we have an accessible section with such:
JAWS transcript:
> Filter  // the short label of the setting type, which  could be Group By, Column Filter, Color  Highlight...
> checkbox checked // The control type
> substring // The description, supported by JAWS, showing the substring used for filtering
> // Down arrow key pressed
> Remove // The label
> Button // The type of the control
> substring // the description, does NOT work in JAWS,  showing substring to be removed

In the component, We may have  unlimited number of settings , multiple filters, group by, View types...
Checkboxes are needed to temporarily disable a setting without removing it.
What if we have 10 filters? We can quickly press Down Arrow after perceiving a label and types ignoring descriptions.
And this works in JAWS for checkboxes!!! If we need a description, we just do not press anything , and we have the description.

But for buttons, we cannot use  the short name. We must use instead "Remove substring", where the substring  is something entered by a user and can be very long.
With accessible descriptions for buttons it would not be a problem.

Compare the visual interface, nobody repeats  the same information twice in the same place.
But we are forced to repeat the same information multiple times (consider  more buttons like "move up substring", "move down  substring".
So, because of this ARIA  violation,   when descriptions are not emitted, we must include this long "substring" to every element, instead of having just an accessible description.
So, we force blind users to listen the same long substring gozillion times, just because then will not get the control type until the whole label is emitted.

### Expected result
JAWS must emit descriptions, or the fact of available description in VPC down arrow mode.
This would allow us, the accessibility developer, to create better  user experience for JAWS users.
And for us, the blind accessibility developers, this would allow to be more productive.

There is another mode in JAWS, SayAll mode. Surely, no need to emit description in such modes. But manual down arrow must emit everything about the element, including the description.

[stevefaulkner]

@BrettLewisVispero @RFischer-FS This detailed exposition is asking for changes in the way JAWS conveys information in VPC. I don't this details bugs per se, but feature requests. This issue is for Freedom Scientific to ponder.

[JAWS-test]

It should be noted that JAWS and other screen readers (e.g. NVDA) do not output the description in VPC mode. This seems to me to be a deliberate decision:

• When I read the content, I don't need operating instructions
• If I want to operate the elements in form mode, I need operating instructions

[BrettLewisVispero]

Imported into ADO as bug 92466

[BrettLewisVispero]

@Vladimir-Goncharov-a11y for form controls JAWS does announce/show the description for form controls such as buttons in the virtual buffer when you arrow to them. You need to make sure the "control descriptions" option is checked in speech options for the verbosity level you choose. This is in settings center.
Do you have a particular control type where JAWS is not doing this? I am sure we don't do this for all control types, but if you have an example of a problematic control type, that would be helpful.