Meeting minutes
New Issue Triage
jamesn:
jamesn: assigning aria #517 to James Craig
pkra: Looks like #2079 relates to new ACT rules?
scotto: Can assign #2079 to me
… I'll respond in the issue
jamesn: aria #514 seems editorial? Please take a look and if you agree, create a PR in html-aam
… assigned to Adam Page
Do we need clarification that generics can be named in certain contexts in the ARIA spec?
jcraig: Yes, I think I created an issue for this; we absolutely need tests and clarification (having a name for an element as part of labelledby computation, although it doesn't get its own name)
jamesn: Isn't it true that authors must not name generics, must there should be a name calculation
BGaraventa: there seems to be confusion on what is a name and what is part of child traversal algorithm; not usually calling out everything that has an accessible name. Just calling out what has actual contents or a label; sometimes not always nameable elements
jcraig: Should make this more clear in the spec; what we've got is a rule that allows 1) verify what is valid in one context and not allowed in another context (for leaf node element); e.g., text <span> will be referencable in its own text node
jamesn: If named a generic in certain contexts, is this an author error or not?
Matt_King: If the thing is referenced by aria-labelled, that thing doesn't have a name; always an author error to put name on generic. But referencing a generic element with label/labelledby doesn't give the thing a name
jamesn: Can someone put in aria #220 what the issue is (with code example)?
BGaraventa: I have a code example and can put it in the issue (accname #220, not aria repo)
scotto: Want to understand the use case; want to challenge the idea that it was ever a good idea to do this
BGaraventa: Disagree that it's an authoring error to name a generic
(disagreement on whether this is an authoring error or not within the group)
jcraig: Unsure that this is fully supported across browsers
jamesn: Please put example in issue accname #220
New PR Triage
scotto: companion issue for aria issue #1880, James N. will assign reviewers
jamesn: core-aam #212 is editorial, Peter K. will take a look (actually, James N. will self-assign)
WPT Open PRs
jamesn: wpt issue #43013 has 2 reviewers, doesn't need more reviewers
… wpt issue #42986, Valerie will re-review
jamesn: for #42769 has multiple reviewers; James agrees it's a good change
jcraig: will re-review wpt #42760
Deep Dive planning
jamesn: No meeting next week (week of Nov 20 due to Thanksgiving); no deep dive either. Anything for after 2 weeks?
<spectranaut_> w3c/
<spectranaut_> was in the agenda ^
jamesn: would you like to talk about html-aam #506 at a later time? Or anything else to be proposed?
aria-hidden=false
<jamesn> in another conversation with @aleventhal about this, it resulted in the rehashing of some of the points raised in this thread, particularly the reminder about JS framework/component libraries having used aria-hidden=false on components that could very well be put inside of an aria-hidden=true subtree.
<jamesn> With that in mind, and the fact that the ARIA spec has essentially warned people away from using aria-hidden=false for years, maybe the best thing to do is nothing for aria-hidden=false.
<jamesn> Aaron created this chromium bug to do just that:
<jamesn> https://
scotto: I can speak to this; for the comment in aria #1256. Spoke with Aaron L. about the aria-hidden=false problem. We've both aligned on the idea that "false" should do nothing; the only place it does do something is WebKit but unsure about the use case
… can navigate to element with aria-hidden=false; so long as no nested elements, will be announced by VO
jcraig: This issue is targeted at never using aria-hidden=none (?); can't "un" inert something. If a view is rendered and aria-hidden on the body, aria-hidden=false could unhide it
… I don't think we should dismiss this idea yet; but don't think we should change anything until agreement on what needs changing
scotto: Not sure what to do then; all the situations where aria-hidden=false is used on elements that would become "unhidden" in situations where we don't want them to. Then, at a impasse if we do, if we don't...so much usage of aria-hidden=false for where it shouldn't be used (e.g., AngularJS)
… in AngularJS, aria-hidden=false is used in a widespread way (for things that should NOT be set to aria-hidden=false). Can understand the use case for what it should/could have been. People are relying on the fact that it doesn't do anything
jcraig: Unfortunate that it does that; flip side is that a couple frameworks misuse it
<Matt_King> I'm going to stay connected and try to multi-task ... at least multi-listen
scotto: I would propose, and someone already said this; I think there is a use case. I wonder if it's at a point where we want the use case to be viable; we need another value, e.g., aria-hidden="unhidden". Then, false can mean nothing and we can move away from that. I dunno, I don't see a path forward with false but I acknowledge that we do want this behavior via new value or different attribute
jamesn: Definitely too much "baggage" for false (aria-hidden value)
jcraig: Once we have isIgnored() as WPT property, then can work out the issues with where it is ignored
jamesn: How do we move forward on this?
scotto: I've talked to Aaron L. on this; I would be happy to write the spec update to indicate that aria-hidden=false is the same as if the attribute isn't there; if we want to do something with a new value, then that would be a different PR. Missed what James C. just said (apologies)...that's what I can do here, then pick up work on what we want aria-hidden=false can do
jamesn: Is it documented anywhere what WebKit does with aria-hidden=false?
scotto: I have a codepen example somewhere; didn't mean to misspeak, just observed that's what WebKit does
jcraig: *unintelligible due to background noise*
<sarah> aria-hidden="really-false"
scotto: I will post next week what the current behavior is (and the PR); can scrutinize it together but we have something we can work on together, people can introduce alternative ideas
jamesn: As long as we have a path forward, great
jcraig: Wanted to mention that WebKit implemented it according to spec (a decade or so again); since then, issues have been raised by Gecko (I believe). Had an interop problem due to stack and expectations changing that haven't been implemented by other engines. But in addition, are real bugs...don't want to change anything until agreement on what's changed. Getting closer to interop is desirable; if too much baggage with aria-hidden=false, can
look into further but will agree with PR likely
[Question] wai-aria/role/listbox-roles.html wpt test
spectranaut_: have we talked about this already? James N. unsure
jcraig: Don't recall talking about this in the group
jamesn: Should consider adding a requirement on user agents? As a should or must?
jamesn: Have a WPT test; there's not a concrete UA must that backs this up
<spectranaut_> this is when we discussed last: https://
jamesn: if we have consensus on UA where they agree what the behavior should be
… Valerie, should we have a prototype for what the procedure should be?
spectranaut_: If there are kinks in the procedure, can work that out
jamesn: Could have a bunch of tests (e.g. with orphaned roles) *which already exists as James C. points out*
… already assigned to Scott; but someone else could take it on
scotto: The WPT test was assigned to me (aria #2012) but happy for someone else to look at it
jcraig: please add me a co-assignee (along with Rahim)
aria-controls spec update
jamesn: I know Matt K. had some stuff on this but he had to leave; he's already added comments
scotto: I've had a long conversation with muan as well; will get to this as soon as a I can
jcraig: Keep on agenda or remove?
jamesn: Leave it on, we have 2 weeks; let's see if there's progress before being re-added to agenda
Windows/Mac differences in presentation of some HTML-AAM implicit roles
jcraig: Is Emilia (?) actively working on SVG AAM mapping? Quite a bit of date and/or ambiguous
jamesn: No actions on svg-aam other than spec maintenance on editorial stuff
… should we talk about this in the next editors/planning meeting to determine what we're going to do?
pkra: Same issue with dpub-aam; we should talk about it
jamesn: for html-aam #467, should we do a deep dive or talk about it in one of these meetings?
jcraig: Not really sure
… possible that these will be easier to work out kinks at a later date; already have rendering differences but for now, not a pressing issue
Consider a mechanism to associate controls without an explicit grouping
scotto: Need to drop now
… (and leave meeting)
jamesn: Should we skip this? OK, let's skip it, or perhaps take up in 2 weeks time?
Consider creation of a fieldsize/maxlength property
jcraig: Yes, we should (consider creation of...) but not until it's testable
jamesn: Talked about in aria spec 1.4, hopefully will be testable by next year
jcraig: Lots of challenges with interop stuff
sarah: maxlength on an input prevents input/typing, not an option on contenteditable
jamesn: Maxlength on <input> exists but screen readers don't do anything with it
sarah: html-aam says it's not mapped in any API
jamesn: Is there anything in the a11y APIs it could map to?
sarah: Just did a bunch of testing on this
… but did not test on iOS; implemented a live region but it isn't a good solution for this. Almost never announces due to character limit so having an api for this would be nice
jamesn: Once we get notifications (ARIA notifications), could work?
… want to know when you have some characters left, and when you are reaching the end (vs. when you get to the end)
jcraig: Seems like on the AT side of things, don't need to spec it
jamesn: Sarah, you've done experimentation and didn't land on a good solution (live region approach not good)
sarah: Can look at what UIA has available; if others (James C.) can look at other APIs
jamesn: aria #1119, should I assign to you (Sarah)?
sarah: Sure