Meeting minutes
title: ARIA Deep Dive - Should form field in cells have name computed from table/grid headers
aardrian6: assume everyone has read the comment
aardrian6: take accname and add another step. If there is a field with no accname but sufficient context then give it that accname
aardrian6: has to have a col/row header associated - if both then would concatenate
aardrian6: broadly my goal is to provide a guessable accname for voice users
aardrian6: and for screen reader users
aardrian6: and also to provide some redundancy for screen reader users would need coordination with AT vendors to coordinate
matt: I read the proposal and understand what you are proposing. Do you think this discussion needs to revolve around the pros and cons of whether this is done at all?
matt: if we don't do this what would we do to solve the problem. What would you like the scope to be?
aardrian6: figured folks who are familiar could do that
matt: what are the plusses of an automatically generated name
matt: versus the cons especially around edge cases.
aardrian6: edge cases... and corner cases where authors would override
matt: this is intended to be a fallback name calculation
aardrian6: i work with authors all the time with these data sttructures who don't want a visible label
giacomo-petri: are you saying that this fallback is a valid solution or is this a fallback that would be managed by user agents
aardrian6: initial thought is that this is just a fallback. but then maybe if this gets iimplemented then would maybe create a wcag technique
matt: seems like a good approach
matt: still womdering whether or not we want it to be an explicit wcag technique
jamesn: would also need stuff in HTML-AAM too
https://
aardrian6: take a little further and look at headers and id. When it comes to contructs that don't have great support. my model is looking at simpler tables
aardrian6: do we run at what support looks like now. or do we wait for browsers to implement that stuff and build it in to that
aardrian6: my thought is that browsers are already responsible for coming up with that.
jongund: there seems to be a difference between grids and static tables. tables would use tabs, grids generally arrow keys. in a static table what do screen readers do now if there is no label
… if using table commands get the label
aardrian6: propose grids and tables are the same
… if via cell navigation you are already hearing this new info - need to discuss with AT how they would do that
jongund: seems like in the past accname type issues - browser developers were hesitant to make changes
aardrian6: understand that concern
jamesn: not super concerned about this
jongund: would we limit to native HTML
aardrian6: th and role columnheader/rowheader are functin
ally the same thing
jongund: don't think it should be a fallback
aardrian6: techniques includes failures and sufficient techniques
jamesn: how do we do it so that AT can make it less verbose?
jamesn: you can do this today, and if you did do it today, how can we communicate to AT that they should not communicate this information
jamesn: in the accessibility API, the AT will not know how the accessible name got there
jamesn: they will have to use context clues
matt: this is good for ARIA-AT
matt: good for ARIA-AT
jongund: already deal with this
matt: but right now they don't deal with this really
matt: the only way we can figure that out is by having a set of test cases
matt: we can write a should expectation in ARIA AT not a must
giacomo-petri:
giacomo-petri: was going to say the input name should be the same as the row/column header. You have the repetition right now. Of course would be necessary for the future.
giacomo-petri: lets assume this proposal comes off. If AT would support this then at the very end this solution would be more accessible. With this solution if AT avoid the repetiition then it would be much less verbose
matt: if this is adopted then it doesn't change anything for AT developers. I think they have to solve the double speak problem today
matt: this is just 1 more way of a browser calculating an explicit name. Any of todays explicit name techniques then AT already has to do things today to avoid extra speech
CurtBellew: Q about a scenario. What do you do when there are multiple controls or a radio group in a cell
aardrian6: if you have multiple then you get the same accname
giacomo-petri: if AT that supports this structure by announcing once. What happens if the author is customizing the accname?
aardrian6: if there are 2 controls and neither has an accname. they both get the same accname. If 1 has an accname and the other doesn't then 1 would follow this.
jongund: more things will get accessible names
StefanS: want to ask if thisn't more a discussion about what screen readers should do not what screen readers should do
<giacomo-petri> <td><input type="text" ... aria-label="input 1"></td><td><input type="text" ...></td>
StefanS: should behave like a table - what a screen reader can do is look at the relationship of the cell.... more a requirement for screen reader builders
aardrian6: no this is not for just screen readers. The accname should be in the browser
aardrian6: redundant fields.... authors should already be doing that
aardrian6: someone should be raising the issue that all fields had the same accname - authors can do all sorts of things.
aardrian6: if someone has the same button 10 times then this doesn't change that
giacomo-petri: we are saying that AT should end the redundancy. Have some cells with an input with no accname but other table cells with multiple inputs then need an accname. Would the AT provide inconsistent feedback. Then the AT would no longer be able to recognise that the AT has been cusotmized
aardrian6: the author is always required to provide an accname. if this lands with support then doesn't change the fact that authors need to provide accessible names
giacomo-petri: talking about consistency
aardrian6: if i am navigating table cells using a virtual cursor then already a verbose experience. Then will hear the accessible name of the fields
aardrian6: would need conversations
jongund: Q? for screen reader users - would row or column number be useful?
matt: no
Mario_B: users decision to hear the number or not
Mario_B: propose to have exact order for accname. If have in a table column headers and row headers we need to say in which order we take these headers into the accname. It is important as the screen readers can then more easily decide how to mute some announcements
aardrian6: would use columnheader and rowheader to build the name. The screen reader would then be able to decide if they want to announce it all or try to concatenate. If the screen reader wants to split that would be up to the screen reader
aardrian6: feel like it is a heavier lift to do that
general consensus is that we should go forward with this