Meeting minutes
<scotto> mark is a wonderful person and i hope good things happen to him
New Issue Triage
jamesn: no new issues today? wow
jamesn: lets peek in one more place
jamesn: okay, cool!
New PR Triage
jamesn: no new PRs? wow! holidays...
scotto: maybe ARIA just works now
[laughter]
Deep Dive planning
jamesn: anyone want to plan a deep dive? we have one on Dec 8
jamesn: aria-flowto is scheduled for Dec 8. only slots we have are Dec 1 and 15
jamesn: hearing none, moving on. I cancelled lots of upcoming meetings, so make sure to check your calendars. Nothing between Dec 15 and Jan 5
Support aria-description - can this be merged? It will unblock a lot.
jamesn: where are we on this one? waiting on the accname editors?
BGaraventa: it's fine with me, i just need to mark it as approved
jamesn: i fixed the merge conflict
jamesn: hoping for Melanie to check it out, too
scotto: i'm okay with it, but i need reviewers on #444
jamesn: jcraig, aaron, and BGaraventa have been assigned
scotto: it's essentially all the same stuff, but in a different spec
BGaraventa: i'll take a look this afternoon
Aaron: I can check it out too
jamesn: once that's done, all the other PRs will have to be rebased on that, since it changes accname a lot
AccName Role Traversal Proposal
jamesn: james teh and BGaraventa have been having some discussions. where are we BGaraventa?
BGaraventa: james teh would like the 'always' and 'never' speced out, and elements that receive focus. he seems against adding that in, based on the github comments. what does the group think?
scotto: i'll give it a read through
scotto: his example of a listbox inside a link... seems like a legitimately weird use case.
BGaraventa: not sure that's a good example
jamesn: essentially what he's saying is correct - it never makes sense to traverse inside certain roles (like a <select>)
aaron: when select-size=1, we take the value of the object to put it in the name
jamesn: but you wouldn't traverse into its children, right?
BGaraventa: we do have examples like that, or like a listbox in a label
aaron: the precedent should be if the thing has a value
jamesn: could result in getting something without an accessible name, if there's no value though, right?
BGaraventa: if that's the only thing you had, sure
jamesn: if the aim of this is to make sure everything gets an accname, we'd want to avoid something like that. but that's not the goal here right?
BGaraventa: yeah
jamesn: i wouldn't want to complicate the algorithm any more than necessary
BGaraventa: an option is that if a focusable element doesn't have a name, then it's an author error
jamesn: yes AND we can state browsers MAY correct that if they want to
BGaraventa: what do you think scotto ?
scotto: i'd rather we go with the least complicated option, and we could take another look at what needs to be done
scotto: we should look into what common situations come up where an accessible name should be returned and isn't
scotto: having it completely reliant on focusability - what does that do with virtual cursors and other forms of non-focusing navigation?
scotto: i'd rathre keep it simple for now and check into the rest later
mck: i'd like to suggest that naming is never dependent on focus, that seems like an inconsistency that could only have negative impact for screen reader users
scotto: the one counterpoint I have is where generics get named by contents, if they have tabindex=-1, resulting in the entirey of an ENTIRE div's contents being the name for a container
scotto: other than that, i totally agree with you Matt
mck: that's a situation where i would argue that, if it does get focused, it's a generic, so it shouldn't be named by content ANYWAY
mck: if we give the browser some wiggle room to do some kind of processing to decide if SOMETHING is better than NOTHING, then that can exist in the spec too
cyns: want to make sure that visually hidden things don't get broken by things like that too, in case they have tabindex=-1 (not that they always have that)
mck: if it's offscreen for the purpose of helping screenreaders, they should be giving it an accname
cyns: yes they SHOULD be, but historically hasn't always been the case
jamesn: can we agree that if tabindex shouldn't effect this?
aaron: if something has tabindex=0 though, that might be a case where we want to
mck: what i have the biggest problem with is something GAINING an accname ONLY when it's focused. that mismatches the reading and focus experiences
aaron: if it COULD be tabbed to (not tabindex=-1), we assign names proactively
jamesn: so when doing that, if you inspect those elements in the dev tools, what does it say about the accname calculation?
aaron: i don't think we have something saying it's been repaired, probably just says "named from contents"
BGaraventa: that's part of our concern - language around that needs to be fairly consistent in Firefox and Chrome
mck: even a junior engineer might find problems otherwise ("Oh, Chrome is doing a repair - what's firefox doing?")
aaron: a good feature add might be to say where the name is from, and something like "repaired" included
jamesn: would you be happy if the accname doesn't include that? or should it be?
aaron: I don't have a specific opinion
aaron: i do see the benefit of cross browser consistency
jamesn: could you point to the code for the repair, so those interested could see what it's doing?
aaron: i'll post a link
BGaraventa: instead of writing something normative, could just be a note that "some browsers may provide error correction" or similar
jamesn: we COULD detail how browsers should do that
jamesn: i'd like to see dev tools getting better, at least where the browser is actively correcting author errors
<aaronlev> In Chrome, the code that decides whether we should traverse an object for it's accessible name computation is called AXObject::SupportsNameFromContents() at https://
scotto: it would make it clear that there's a mistake
<aaronlev> It takes a boolean argument, |recursive|, which is true when it's in the middle of computing the name of an ancestor
<aaronlev> there are lots of comments in there -- please let me know if there are areas you see that need clarification
jamesn: this sounds similar to what James Teh wants to do for a title on an image - the author needs to be aware they did something wrong. if dev tools can expose that, great, rather than "I guess it works fine, great, ship it"
cyns: could we make this an issue so we could pass it along to those that can do it?
cyns: no urgency, but it'd be helpful to have
scotto: where could I file it?
cyns: cr-bug, cr-featurerequest? against Chrome
jamesn: could this be a deep dive topic? With James Teh? He works with Firefox so it'd be good to have Google and Mozilla convos
jamesn: before the holidays?
scotto: no [laughter]
jamesn: january would be great
cyns: i'll find some folks to join us, too
BGaraventa: how should we get James to reply/come?
jamesn: pretty responsive via github
cyns: and email
BGaraventa: can we summarize this proposal?
jamesn: we would allow browsers to repair things as they like, but WHEN repaired, we want them to flag it as such, so authors don't have a false sense of correctness
cyns: to make it clear in dev tools that it works because it was repaired, not because it was correct. not visible to the average user
BGaraventa: support for adding a note to accname spec, that this repair might happen?
jamesn: that seems a natural place to put it
cyns: might even be a MAY, not a note
aaron: another good thing might be to say browsers need to document what repairs were done so we can compare results as testers
cyns: browsers must?
jamesn: it'd be hard to get through CR without checking on that
jamesn: browsers SHOULD, might work
BGaraventa: i like SHOULD over MAY
jamesn: in some cases, it might be do nothing and don't repair, with good cause
mck: documenting what repairs are done sounds good. a requirement to reveal a repair could be a SHOULD
jamesn: maybe a MUST if we can get the browsers to agree
cyns: that might be a separate issue then
BGaraventa: i'd need help with the actual wording of that from the implementers
BGaraventa: but i'll make a comment of all this to james teh, and let jcraig know about this
cyns: two actions - 1) browsers SHOULD repair ... 2) an issue about adding "browsers MUST document repairs" or similar
scotto: is that to be done here or in ARIA proper?
jamesn: we'll figure that out later
mck: why would we change browsers MAY repair to browsers SHOULD repair? not sure we entirely want them to
mck: when authors do something incorrect, having inconsistency across browsers can be advantageous to give authors incentive to correct things
<jamesn> we have may, should and must in the correcting author errors section
<jamesn> https://
cyns: assuming people test a11y cross browser
cyns: assuming that people don't just use what they're comfortable with, rather than checking everywhere
cyns: i'm fine with MAY or SHOULD
jamesn: in that section about repairs, Matt, we have MAYs, SHOULDs, and MUST NOTs
mck: sounds like we need a MUST [laughs] "MUST reveal repairs"
BGaraventa: there's the other side of the spec change, always traverse or never traverse, what do people think?
jamesn: if we can infer it without having something split it, great. if it's not there, we can add it.
BGaraventa: james teh is in agreement to adding traversal property to spec
BGaraventa: what's NOT in agreement is what roles should ALWAYS be traversed, and getting that agreement might be difficult
BGaraventa: i'm not exactly sure what everyone wants, we've seen what i suggest, and if people could change that/modify to what they think, so we can get a proposal together, that'd be helpful
jamesn: has anyone gone through what you wrote BGaraventa to see if that's what Mozilla or Google do?
BGaraventa: i haven't done the backend part yet
BGaraventa: i'll ask james teh, he's got ideas of what should and shouldn't be included
aaron: jamie has strong opinions about it
jamesn: in the issue, theres a list of what Chromium and Gecko do for their mappings
aaron: i pasted the link about Chrome's computation above. it's mainly a switch statement, should be pretty readable
jamesn: this is where i got the information for the spreadsheet
aaron: there's some rules for the body element that are kind of unique, is something tabbable just because scrollable, some pragmatic type of rules
aaron: if something has lots of descendents, it's expensive to compute all of that, bad for performance
aaron: there's a max number of nodes with a named from contents calculation
BGaraventa: there should be a character limit in that case, maybe
aaron: doing it by number of nodes is cheaper
aaron: lets table this conversation about repair. it'd be nice to get info from devs about pain points re: browser differences and AT differences, what's making ARIA devs lives difficult, etc. Look at this as PMs rather than cleanup
cyns: +1
BGaraventa: yes, tabling for later sounds good
BGaraventa: i'll ask james teh if he can modify that list with his suggestions
jamesn: sounds like a way forward
ARIAMixin and ElementInternals - Feedback requested by Anne
jamesn: Anne is asking for feedback on his plan - i'm having trouble understanding it
jamesn: is everyone good with the plan, or not understanding it?
aaron: let's find someone who makes custom elements and makes them accessible for their opinion
cyns: i can find some salesforce people, maybe from the AOM meeting
Define how custom elements are exposed to AT
jamesn: an associated issue, can we talk about this with AOM too?
cyns: yes
1.3 blocking issues agendabot]
jamesn: anyone have updates on these? if not, this is your reminder to work on them
jamesn: hearing none, have a great day everyone!
jamesn: no meeting next week - enjoy your holiday! next meeting is Dec 1