RE: Radio and check boxes inside the table

Thanks, at its core this is a screen reader issue where a bug needs to be filed with the provider, saying that, if a column header matches the form field label, then this should only be announced once. Otherwise, if the column header is different from the form field label, then both should be announced.

Unfortunately there are no techniques for reliably suppressing this duplication in a way that doesn’t screw up announcement on other devices and platforms when navigating in diferent ways, such as by touch, or by tabbing, or by arrowing through virtual content, or by swiping through each object, or by jumping between specific control types, etc.

I think the safest course is to file a bug that reproduces the issue exactly, and then submit this for the AT provider to fix.




Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Gunderson, Jon R <jongund@illinois.edu>
Sent: Thursday, September 5, 2019 9:41 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Schnabel, Stefan <stefan.schnabel@sap.com>; Sina Bahram <sina@sinabahram.com>; 'sirisha gubba' <nsfsiri2014@gmail.com>; 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: Radio and check boxes inside the table

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

I think the problem Siri raises is that the assistive technology is not using just the accessible name available through the Accessibility API, but also providing additional table header information, so information is being spoken twice.

What can the author do to suppress the table header information from also being read, when the control already has a label.

Jon


From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Thursday, September 5, 2019 11:32 AM
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>>; 'sirisha gubba' <nsfsiri2014@gmail.com<mailto:nsfsiri2014@gmail.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Radio and check boxes inside the table

That’s true.

If you want browsers to do this, then we need to add all of this to the AccName algorithm. At present there is nothing like this, and I’m not convinced we need it. Double speaking is annoying at times, but I’ve seen too many examples in the past when table formatting is not reliably conveyed by the screen reader and implicit labels for form fields placed within column headers are not in the correct reading order and appear nowhere near the form field that needs to have a valid name. In these cases it is nearly impossible to identify what goes where.

Tables are tricky too, such as the cases where there are complex data tables with multiple column headers. I think these are rabbit holes where it is simplist to simply add a title attribute to the form field in question and add an accessible name. This works on touch devices too right now. ATs can then be programmed to ignore name and description property duplication so that only one is announced. I don’t think this should be overly difficult.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>
Sent: Thursday, September 5, 2019 12:52 AM
To: Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>>; Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; 'sirisha gubba' <nsfsiri2014@gmail.com<mailto:nsfsiri2014@gmail.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Radio and check boxes inside the table

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

This topic is nothing but an expectation not met.

The expectation is:

WHEN I PUT AN ELEMENT THAT NEEDS A LABEL IN A TABLE CELL AND HAS NO OWN LABEL DEFINED THEN THE BROWSER SHOULD AUTOMATICALLY MAP THE SURROUNDING CELL HEADERS OR ARIA-LABELLEDBY PROPERTY TO THE LABEL RELATION OF THE CONTAINED ELEMENT.

Browsers don’t do that. That’s because nobody told them to do so. Reason unknown. I can imagine it will have side effects. And this won’t solve the validator problem either.

What you find instead is that you put the burden on the AT and the validators. Both should go on DOM structure, analyze on focus where they in (table cell) and speak and accept any existing headers or aria-labelledby attributes.

AT and Validators don’t do that. That’s because nobody told them to do so. Reason unknown. I can imagine it will have side effects (huh, sounds familiar).

Regarding redundant speaking in general:

The best practice would be that redundant speaking is handled within Assistive Technology (authoring errors explicitly excluded). Provided the fact that you have two identical text strings in two different properties (this MAY happen) there could be AT settings like “ignore when identical” or “speak only when different”.

This is not necessarily related to ARIA or table stuff and can also be done for cases like

<button title=”This is a long truncated text”> This is a long truncated text</button>

where the visible UI text because of button width limitations will be abbreviated by the browser to “This is a long..” and the tooltip will hold the entire text.

Often, authors cannot foresee the width and to “be on the safe side”, use the title to back up those cases. You can debate for ages if this is good or bad but the consequence is that both texts would be spoken by AT on button focus. A setting like “speak only when different” definitely helps here (e.g. screen reader Jaws has that), but the PROBLEM is that you would need such a setting for MANY roles (not just buttons and links). Jaws limits itself here unnecessarily, in consequence, those settings do not work for certain other ARIA roles that use visible label strings.


  *   Stefan

From: Sina Bahram <sina@sinabahram.com<mailto:sina@sinabahram.com>>
Sent: Wednesday, September 4, 2019 6:30 PM
To: 'Bryan Garaventa' <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; 'sirisha gubba' <nsfsiri2014@gmail.com<mailto:nsfsiri2014@gmail.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Radio and check boxes inside the table

Building on this, is there accepted best practice on how to avoid the double speaking?

President, Prime Access Consulting, Inc.
Phone: 919-345-3832
https://www.PAC.bz

Twitter: @SinaBahram
Personal Website: https://www.sinabahram.com


From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Wednesday, September 4, 2019 9:30 AM
To: sirisha gubba <nsfsiri2014@gmail.com<mailto:nsfsiri2014@gmail.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Radio and check boxes inside the table

Hi,
This is because the table structural relationship is not a valid naming mechanism, so it may be announced by some ATs in some cases, but it’s not reliable. E.G. Likely the label will not be announced when the form field is navigated to on a touch screen device like iOS. This is because it needs to be labelled properly using a valid naming mechanism for this to work equally across devices.

All the best,
Bryan

Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: sirisha gubba <nsfsiri2014@gmail.com<mailto:nsfsiri2014@gmail.com>>
Sent: Tuesday, September 3, 2019 11:14 AM
To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Radio and check boxes inside the table

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

If a radio button or check boxe is used inside  a <td> cell, why does it need aria-label or aria-labelled by attribute added to it?

The radio buttons are inside the table,  so the relationship has been established between the table headers and radio button in <td> cell.
 Adding aria-label makes the screen readers to narrate the radio button's label twice.
If I remove aria-label from the radio button (which is in a <td> cell), automated tools are flagging it as error.

Can you please advice?


Thanks,
Siri