Meeting minutes
New Issue Triage<https://bit.ly/2Le1JDF >
JN: 5 new issues. top two accname
JN: 1389. https://
Joanie: possibly. but could the new roles related to presentational mean we need to address this in 1.2?
JN: This does seem to relate. These are two nuances it seems
JN: https://
JN: 1386 we addressed last week
New PR Triage<https://bit.ly/3oM7S7E >
<carmacleod> https://
JN: one PR -- https://
JN: has 3 approvals so is everyone ok with moving forward?
jcraig: I do have a question but I think we should merge it in. The last comments
MK: we're removing things that were previously added right?
jcraig: right
JN: was this really added? This was in Core AAM and has been moved to the spec
MK: In that PR we had a clarification of what was in Core AAM. So we changed it when we moved it over
<jamesn> "Elements that are focusable, or have an ID attribute and an ancestor with the aria-activedescendant attribute that matches the implicit or explicit semantics of the required context role. In either case, the element may receive focus and may fire an accessibility API FOCUS event."
JN: We did change it.
jcraig: the big change was to clarify around aria-hidden
<jcraig> short summary: it was "expose anything *focusable*, even if aria-hidden". It's now "expose anything *focused*, even if aria-hidden"
MK: if you're telling authors what you can and can't do with relation to aria-hidden then can you tell them what to do with focusable
MK: seems you can't. if the element is focusable then it's impossible to keep it out of the accessibility tree
MK: hidden from AT users but not hidden from other users. AT hidable is not possible across platforms for focusable elements and that's how we want it?
jcraig: it is possible to make it hidden from both AT and other users (tabindex="-1")
JN: Thre are other ways to remove elements from the tabindex
JN: We don't necessarily want any solution that requires setting everything to tabindex=-1
jcraig: Trapping (correctly) is difficult. Most authors that use a keyboard trap break the users experience when tabbing or shift+tabbing out of the web view into the browser UI
SH: It's doable
SH: we listen for the key event. It's not simple but it's not too hard
JN: So, aside from how it's done let's assume people will want to do it to accommodate things like dialogs etc
MK: We want to avoid a side effect where we prevent aria-hidden that could be legitimate. Is there something could prevent that?
JN: This change is making it more possible to do things than it was before
Thanks, jcraig. difficult to keep up.
jcraig: makes it possible to use aria-hidden the right way and will prevent bad impact when a mistake is made in using aria-hidden
MK: Authors do have more control as a result of this. we should be able to reliably hide focusable elements from AT as long as they don't get focus.
MK: Approving this PR
jcraig: moving that we merge this.
JN: agree. Merging
Meaty topic for next week<https://bit.ly/3oILEDE >
JN: do we want a deep dive next week?
JN: [silence] No deep dive next week.
Follow-up: tree inclusion of focusable elements from #1100<https://github.com/w3c/aria/issues/1381 >
JN: we talked about this one so we can move one. We have the approvals to move to CR
<jamesn> https://
jcraig: ARIA 1371. Ability to prevent AT detection
jcraig: We could do this for the deep dive next week
JN: yes good idea
MK: deep dive to work on the language to add?
MK: Don't we need to add language to express a goal or intent to prevent AT detection. Other specs hve that language but we do not right?
JN: That language exists but it is very incomplete. The ARIA part isn't the part that prevents it necessarily
jcraig: Detecting AT really has nothing to with ARIA. We can't address it completey by adding it to our spec. We need to bring that to the attention of other groups
MK: do you think there should be the ability to adjust user interfaces based on what technologies people are using in a way that protects privacy
MK: media queries for reduced motion, high contrast settings. things like that. Do those fall in to this space?
jcraig: to some degree media queries don't necessarily associate a user with a disability.
jcraig: some of the other methods could be used to associate a user to a disability
jn: This seems like a topic for next week.
MK: to what extent should have the conversation inside ARIA before we talk to the privacy group
MK: I think I'mnot as all or nothing. I want to protect privacy and a lot of situations where adapting the user interface to create a better user experience has been extremely valuable
MK: To me not much different than responsive design because it makes the experience much better
jcraig: I don't disagree. I have suported a way for a user to opt in for user preferences allowing this. It's just a question of what could be abused to detect that an AT is being used
jcraig: the future conversation about allowing a user to opt in feels like another conversation
JN: if the privacy group can't make it next week I propose we have a conversation amongst ourselves
JN: to get a more consistent path forward
jcraig: could we meet the 25th?
JN: proposed to meet with privacy group next thursday. So I'd like to go ahead with that
<Zakim> jamesn, you wanted to ask to discuss next week and to ask to discuss next week
Action: james to merge 1381 into stable and CR branch
ACCNAME<https://github.com/w3c/accname/issues/97 >
JN: We need answers from people. They are now in Github. If you have an opinion on how accname should work or you want to walk through the steps and offer an opinion that would be great
JN: the comment we have now is about what the browsers currently do as opposed to how accname should work here
CM: The current answer is helpful in understanding how it works now
JN: We really want to put aside what the browsers currently do so we can determine what they should do ...
MK: We an analyze the current algorithm to understand what it does. If we want something different it's useful to say what should change in the algorithm and what the consequences might be
Updated aria-setsize and aria-posinset to clarify usage for authors<https://github.com/w3c/aria/pull/1332 >
JN: waiting for reviews.
JN: jcraig, MK as well as JN are down for reviews.
CM: this adds one normative change. This change goes one direction and not the other. this is what we want. There's a paragraph in each spec that talks about how the user agent can automatically calculate
CM: If only a portion is available at any give moment then this property is needed
CM: This paragraph seems to contradict
MK: I don't like the language there because it seems to place an additional requirement on the author.
JN: I think we can make the second sentence in to a normative requirement.
<jamesn> action, james to add comment to PR 1332 to author requirement for posinset if start of set is not present
Action: james to add comment to PR 1332 to author requirement for posinset if start of set is not present
jcraig: changing some phrasing. Changing property to attribute.
JN: Can we make this a separate issue
Spec is unclear on aria-invalid="spelling" | "grammar" uses<https://github.com/w3c/aria/issues/989 >
JN: I'm asking for more thumbs up or down on the straw pole
JN: Is the current markup supported today? If so then no need to change it