Meeting minutes
scribe pkra
New Issue Triage
<Adam_Page> binks and bonks
jamesn: issue triage. accname #234
New PR Triage
jamesn: html-aam #539
scotto: addresses issue via html. Handles obsolete elements.
… browsers have recently added visual styles so we might want to match it.
jamesn: any reviewers?
jcraig: I'll do it.
WPT Open PRs
jamesn: do any need additional reviewers?
Rahim: not right now
Deep Dive planning
jamesn: we have an opening next week
Data grid example, form field missing accessible name
mattking: originally from APG. We transferred it over.
… there's a general question when you have inputs.
… this is grids but likely applies to tables, too.
… grid with input in a cell and column header.
… the accname calculation does not treat row/column headers as accessible names.
… Wilco raised it from a checker perspective.
… adding labels creates negative impacts though.
… e.g., if you have header announcements turned on, then you'll get duplication.
… maybe it's WCAG or HTML but felt like it isn't APG
giacomo-petri: I think repetition may be frustrating but perhaps the right way.
aardrian: I see 2 issues. There's a bug in the example (fields without accname). Then there's a valid use case for accname calculations to pull from headers if there is no accessible name.
mattking: in APG, if we add an accessible name, we tell people that this is what we want them to do.
aardrian: do you want authors to author it this way, trigger warnings and risk screenreader users problems in sequential?
mattking: I think I might.
aardrian: I'm concerned that without the fixes this will cause problems.
jamesn: having something in APG that fails is not a good idea.
… I've come around on supporting headers in accname calculation.
… it seems like it might not even require a change in WCAG.
sarah: is the desired solution to have browsers automatically calculate or to say that form fields in table/grid with row/col headers don't need a name.
… one solution is an author convenience (no need for labelledBy) or you have the double labels problem.
… not having a label seems like a WCAG change.
jamesn: I'd agree.
mattking: I think I also agree on a WCAG change.
scotto: if accname updates to auto-name form fields in cell, that would create the verbosity issue; also it would need extra rules (e.g., both headers, two inputs in cell).
… maybe we could also petition screenreaders since they've resolved it for some situations to avoid duplication.
Adam_Page: on the APG end, can we add a note to be transparent that it doesn't conform to WCAG right now but we are working on a resolution?
jamesn: I agree.
<SoARIA> i'd be surprised if WCAG would entertain changing per this scenario
aardrian: I agree - a note would be useful. Even if developers ignore those.
… for accname. the verbosity doesn't change but seems like we could work with screenreaders to reduce the verbosity. Especially since they already have special rules.
… mostly, I would like to find a way to provide usable labels from what's already there.
bryan: agree on the above. I think the complexity of adding this to accname will be a challenge.
mattking: seems like we have 2 near term solutions for APG.
… First, we change accname but since it's programmatic, screenreaders could dedupe.
… second, change WCAG so that lables aren't required in this context.
… third, ask screenreaders to fix the problem so they use the context. Not sure this none is realistic.
… I'm only aware of 1 situation where they're not good at announcing. Usually it's good row/column information
Rahim: regarding inferring name from context more broadly.
… seems different from what accname usually draws on.
… feels more like guessing.
bryan: I'd say it's problematic since it's subjective.
… in a dialog with multiple inputs, then you might get something on opening but tabbing through you won't get anything.
jamesn: going back to matt's 3 possible solutions. I'm not sure if it's enough we say empty accessible names and associate it. WCAG only requires programmatic determinability.
… probably just a change in techniques.
… would need changes in checking tools.
mattking: that's a good point. I think I agree that that's the right way to move forward. Screenreaders can then use that programmatic determination.
… that seems doable.
jamesn: I'm not 100% sure I'm reading WCAG correctly.
mattking: I brought this over. I'm not sure I want to take this to WCAG right now.
… I do want to add a note on the example.
… also open a WCAG issue referencing the APG and ARIA minutes.
… should we leave this issue open?
jamesn: yes until we have a conclusion from other areas.
… would love a note sooner rather than later.
<aardrian> +1 on a note in APG sooner rather than later.
mattking: there's another issue from wilco in APG that's almost identical.
jamesn: could we reach out to AT?
… to see if they'd be willing to infer.
mattking: we could bring it up in aria-at.
jamesn: that would be great.
<aardrian> Side question: "AT" means screen readers, right? How does this address voice control?
bryan: is this issue also for tables?
jamesn: yes.
bryan: and both aria and native tables acting the same?
aardrian: yes.
bryan: there's the header attribute there, no?
aardrian: but not well supported.
marquee and timer listed as live region roles but have intrinsic aria-live="off"
jamesn: I find the current situation reasonable - only read out when on the elements but otherwise off.
mario: but if I only get it when it's focused, then I don't need a live notification.
jamesn: but you'd get the change while you're on it?
mario: I would appreciate a way to get notifications without having to move to them.
mattking: maybe we don't mean "focus" but more "screenreader point of regard"
… we don't have any language in the spec to explain that.
… I would like to have language that explains that.
… so you get updates when you're there.
… it also seems doable.
… I've noticed a lot of inconsistency across screenreaders and applications.
… sometimes they do work this way but I don't know if aria-live is involved.
daniel: to clarify, why is this necessary? If I have focus on the element and it changes I will get the update, no?
mattking: I don't think so.
jamesn: yes for progress bar.
daniel: time bar on multimedia and I think many others.
jamesn: also a plain paragraph that updates?
daniel: but usually they do, no?
mattking: I don't think they do.
bryan: for static elements (span/div), in JAWS when you arrow to it and it changes it usually isn't announced.
… even reading the current line it won't necessarily. Likely due to virtual buffers etc.
mattking: have you experimented with which JS changes would trigger what?
jcraig: I agree with matt. When they do, I think there's extra work that's gone into it.
… progress bar, timer have special behaviors. Additionally, there's live region handling e.g., atomic, it won't follow the same rules if you're on leaf in a paragraph
… and some bold text earlier in the paragraph changes, you won't get an announcement.
… you might have a watch point in a screenreader, e.g., table cell for total.
… I think it would be a good change, specifying a new value that clarifies this.
jamesn: why would we change off? Would that not cause unexpected changes?
jcraig: ok, maybe leave off alone. I think people misunderstand off.
jamesn: can we clarify it then?
mario: better to make it silent, I think. off is not nice but a lot of people do it.
jcraig: I think there's precedent. E.g., adding role none to avoid confusion with presentation.
<SoARIA> so "off" and "silent" would be the same, and we'd need to define "undefined" which is not part of the attribute's values now
jcraig: I think the problem is that people confuse off with undefined.
mattking: to clarify: off means speak when focused or never?
… I don't like silence though because it isn't.
… the others mean they are spoken without being "on" the element.
… but it should be a word that tells people that it will be announced when focused.
jamesn: to wrap it up: a new value to mean what off is (much like none/presentation)
mattking: do we need to define undefined?
jamesn: I'm not sure.
… spec says "off" is the default.
mattking: that's odd.
jamesn: does AT do anything when "off"?
bryan: it doesn't do anything.
jcraig: I'm not sure.
… that's why I'm focused on testing...
jamesn: can you do more research?
mattking: I do know voiceover can tell me how many live regions are on the page. I'm pretty sure that this counts the ones that are off.