W3C

– DRAFT –
ARIA and Assistive Technologies Community Group

21 January 2021

Attendees

Present
jongund, juliette_mcshane, Matt_King, sina_bahram, westont
Regrets
-
Chair
Sina Bahram
Scribe
matt_king

Meeting minutes

<jongund> prsent+ jongund

<jongund> https://www.w3.org/2001/12/zakim-irc-bot.html

<jongund> https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<jongund> https://www.w3.org/2002/03/RRSAgent

Role announcement consistency

sina: example is tablist

JAWS and NVDA announce the role differently.

Do we take a position on that?

Should we enforce consistency?

Or, is the role somehow indicated, generically?

mk: That's reason we use word conveyed

Sina: consider combobox

Mac is different because it announces combobx as popup buttion

Westin: true for html select but if you use role combobox, Mac will say combobox

Sina: need to be specific about browser, Chrome, Sina thinks it does not say combobox

mk: Describe my position about Mac, which select only combobox can be announced in way cionsistent with native, which is popup button variant.

mk: We can convey the essence of the role, or the nature, but the exact word is not necessary.

Sina: +1 to that

mk: There could be roles where we don't want the screen reader to just spit out the aria role name

jg: How is important that reading mode and forms mode are consistent?

Sina: Think they can be different

Sina: They might flatten in in forms mode

In a tablist, they might not want to say the entire role name

jg: Jon, when testing, I observed some differences where group was used instead of the actual continer name

Sina: Should we take a position on whether the words used in reading and interaction mode should always be the same?

In other words, a test would fail if it said tabs in ineraction mode but tablist in reading mode

mk: I support that

jg: what if it said group in vc mode and tabs in interaction mode

WSina: I think that would be a fail

This topic is discussed in issue 366:

https://github.com/w3c/aria-at/issues/366

mk: on example of table, it must distinguish static table from interactive table

oops, meant that to be about grid, distinguish grid from static table

Sina: How do we convey this concept to testers?

mk: I think we need a table of screen reader role translations

mk: This could be a table of exceptions, where screen readers do not precisely announce what is in ARIA

Sina: must be versioned

No idea what this means for internationalization

jg: What happens when people are comparing results

Sina: that is part of the process

jg: This is adding complexity

Sina: is it avoidable?

jg: Do we need this nuance at this level?

Do we rely o the community to flush this out.

What if users, lots of users agree that table is just fine instead of grid

Sina: Just because users think a bug is OK, that doesn't make it ok

Sina: There is a certain clas of things that it is essential that we convey the exact nature of things

jg: Should assertion be "conveys the interactive nature of grid"?

mk: That means we would have to change all the assertions to explain the meaning of roles

Sina: What if we added notes to tricky assertions

Sina: major takeaway, from test writing perspective, we don't change assertion language.

But, we do need to figure out how to create this exception dictionary

We would need to figure out how to roll it into the app, maybe another csv file

jg: It could be another note in the list

in the test runner

Sina: yes

A test writer would update this spreadsheet when coming across an exception.

Should be siome consensus rules around that.

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

Diagnostics

Maybe present: jg, mk, sina, Westin, WSina