Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: ARIA #2756 looks editorial. Part of the large aria.js PR #2501. Is it ready for review?
pkra: Asked Danielle if we can have a diff, put a manual diff at the bottom. Would be nice if we had an official diff
… essentially it fixes some code that incorrectly generates the informative tables
jamesn: Daniel, can you create a real diff?
Daniel: I will try to write it
… perhaps next week
jamesn: can you assign me as reviewer after the diff is done? Thanks
jamesn: Peter has already reviewed ARIA #2754; should we have other reviewers?
giacomo-petri: yes; not sure what we should use here (i.e., SHOULD language)
pkra: my criticism is not around MUST, it's the inability to test the MUST (automatically). How do we know what the author has done
… seems more WCAG-related rather than ARIA
giacomo-petri: yes, but the intent of `aria-busy` is to make users aware when content is updating
pkra: perhaps the ARIA specification isn't the place to specify it's a MUST
Matt_King: seems like an ARIA problem when `aria-busy` is true
Matt_King: can add me as a reviewer. Should it be agenda+?
jamesn: I don't think so. Any other reviewer volunteers?
Rahim: should this be a heuristic?
jcraig: the only way I see it being a heuristic is if the relaxed rules were different than what's codified in spec. Sometimes that's because there's differences or ambiguity (or difficult to spec it due to inherent complexity)
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: since Scott on the call, will defer to him if there's more to do on WPT #52480, and Adam's comments. Is this ready for re-review, Scott?
scott: I think so
jamesn: why is there stuff here that hasn't been merged?
jcraig: a good thing to put on the agenda for the next interop a11y meeting
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: two items: gathering ideas for dev tools improvement (might be a good TPAC topic, could be done earlier); scoping `focus group` to scenarios defined by aria roles and overlap with `aria-actions`
… a deep dive could help with focusgroup discussion outside of Sarah H.'s conflict
Are there use cases for logical properties in aria-orientation?
<Jacques> I can chat with Sarah about that as well, I'll be likely be working on actions at some point in the near future.
jamesn: we are unsure what this issue means (e.g., `inline`, `block` values) for `aria-orientation`
scott: using `inline` for left/right navigation, and `block` for vertical navigation. Just different terminology
<jamesn> q_
keithamus: if you set `writing-mode` to horizontal (CSS), inline becomes vertical axis and block becomes horizontal axis. Horizontal writing mode is default; japanese/chinese use vertical writing mode
jcraig: I'm confused about this distinction; horizontal refers to horizon line and `aria-orientation` is used for scrollbars/sliders. I'm familiar with different directionality of writing systems, but having trouble understanding how `inline` and `block` would make difference in the case of `aria-orientation` which is used for those types of controls
… I would like to understand the context; is there a change we can review related to this?
scott: was only just noting that it wasn't an uncommon thing out of left field
pkra: I was having a conversation with a developer who was dealing with ARIA and writing direction changes. They haven't run into any problems but since they had to deal with both, and they looked at `aria-orientation` and were in touch with the problem of writing directional changes, they wondered if it was something they need to think about. Was it possible to do via CSS? I brought it up to ask if other developers have run into this
consideration, and for other widgets such as scrollbars/sliders/tabs, and it's where directionality could coincide with orientation. If other devs have, I'd love to know how they handled it
… `focusgroup` is another good example of this (directionality)
jamesn: I'm having trouble imagining how someone would create a horizontal accordion if one had a vertical writing direction. Having a hard time visualizing the layout, although it's possible. It's probably not something most developers have thought about
<Jacques> This is the "old" version of the explainer btw
<Jacques> Not the one that is actively being developed.
jamesn: when we look at the ARIA spec and think about what orientation applies to...do widget controls in the browser respect writing direction or is it just text blocks?
<Jacques> inline/block is roughly the same though.
jamesn: should look at applying directionality on a selective basis perhaps
<Jacques> https://
scott: look at latest `focusgroup` explainer
<keithamus> data:text/html,<input type=range max=100 min=0><style>*{writing-mode:vertical-rl}</style> <Rahim> jcraig: I had a similar question: does anyone know offhand if there's a UI control that automatically switches orientation based on writing direction? E.g., a slider that defaults to horizontal, if it were japanese for example. Maybe the AAM mapping should adjust
<Zakim> jcraig, you wanted to ask if there are any related renderings that change when the writing style switches to vertical... For example, do sliders change to vertical?
keithamus: see `input type="range" `example I posted in IRC
jcraig: maybe the mapping is tied into HTML/CSS AAM which changes the `aria-orientation` to vertical
Matt_King: are you suggesting that the browser does this automatically when the browser maps a11y attributes in the a11y tree?
jcraig: may be confusing to authors to change the meaning of these `aria-orientation` attribute values
jamesn: the control itself would have to (a custom scripted control) know the writing mode
Jacques: if author noted `horizontal`, how does this map to screen readers? Specifying `inline` or `block` allows browsers to compute directionality
keithamus: the issue here is that the writing mode is controllable independently from HTML; the orientation is either horizontal or vertical, this can be controlled via CSS. I think it's reasonable inline/to have these terms (block/inline)/inline and the engine can resolve those to the computed style (allows developers to abstract away horizontal/vertical to one location where they set the writing mode, and have browser figure out what they mean via use of
logical properties)
jcraig: having trouble understanding why we need a separate ARIA value for that? If you're using ARIA in this scenario, you're trying to override what the browser has done automatically. Or you're rendering something custom, you're not relying on the browser (browser doesn't know what the orientation is so you must be explicit). If you're leveraging `input type=range` which happens to be vertical, do you need `aria-orientation`?
<Zakim> jcraig, you wanted to discuss the mappings in https://
keithamus: problem is you're already authoring HTML which is the orientation of horizontal, if the `writing-mode`changes, the browser responds to that (although the visual orientation is now vertical)
… developer use case is that, in CSS you can write stuff that is flexible to writing mode; the ARIA override does not allow the abstract notion of block vs. inline. The implementation should be such that, if you've specified implementation of block for example, the value of `aria-orientation` changes (via mapping and browser calculation)
… when I press one of my arrow keys in AT (at interaction time), dynamically figure out writing mode. Difficult to do this via HTML (reacting to changes in computed CSS styles)
jcraig: regarding increment/decrement AT events; AT needs to know what event to synthesize depending on writing mode (e.g., horizontal modes like French/English, RTL languages like Arabic). In VO on Mac, you can send arrow keys through or use interaction mode which synthesizes up/down keys for increment/decrement for example. Hope it's clear that user agent implementation range is what author has intended; concern is that there's a scenario
where the browser engine has an implementation and the author is listening for keys and gets the wrong one
Matt_King: my concern is, if we have these new values for `aria-orientation`, is that they would never be exposed to user via a11y tree. This isn't a situation where you're using ARIA to override to something that the user agent is going to do, it's more like the user agent should do it for the author (and pump out horizontal/vertical to the AT). This seems unprecedented as far as ARIA
<Zakim> jcraig, you wanted to discuss examples like a circular slider
jcraig: as a circular slider example, it could be left-to-right circular slider (or right-to-left). As far as assistive technology experience, users don't need to know, they are either incrementing or decrementing; since this is a custom control, is this a scenario where you need to explicitly state directionality
Matt_King: Right/Up and Left/Down do the same thing in this scenario
Matt_King: Highlights different in LTR vs RTL languages (right is increase/increment in LTR languages)
Jacques: if someone made a toolbar which is horizontal, but the CSS is a vertical mode and they used `aria-orientation` (or a vertical toolbar for example), what should the AT experience be
jcraig: because you're using a toolbar as a managed widget, then the controller for that view should update `aria-orientation` property
Matt_King: big question is who is responsible for that; is that the author?
jcraig: maybe it doesn't matter if the author is doing the right thing, left/right (or up/down) moves focus and maybe it does the right thing and an AT user doesn't need to know
Matt_King: in a toolbar, you often only want to use one set of arrow keys (due to drop-down, submenus or combobox implementations)
keithamus: I agree with Matt; main value of this is for web developers. Without implementing block/inline, it is incumbent on the author to ascribe action to arrow keys (without specifying writing mode). There's an additional step that they need to take to set orientation depending on writing mode
Matt_King: is there a use case for aria-orientation where an author is relying on `focusgroup` which changes arrow keys based on CSS. Does it do that?
keithamus: for a custom widget, it may be responding to arrow keys but based on computed style; it's too difficult to set `aria-orientation` because there's no way of notifying the element that writing mode has changed
<Jacques> and at the point the arrow comes in, its too late to set the aria-orientation, they would have to be watching style
keithamus: when the attribute is set, no way to know writing mode
<Zakim> jcraig, you wanted to ask if there's IDL precedent for anything like this.
jcraig: I'm coming around to this. Is there IDL precedent? May relate to some of the IDL challenges Rahim encountered. E.g., aria-orientation, can't have different IDL defaults based on role. The approach that may work is having a browser default (null)
… in such cases, the default value could either come from the browser or author (e.g., custom slider)
Jacques: even without `focusgroup`, challenging to determine the orientation (and querying computing styles)
<scott> instead of taking up speaking time, i'll just say +1 to much of what keith just said. it seems like it'd be favorable to add these values for cases where orientation could be variable - and thus an author could just set one of these values as their default, and then not have to worry about updating the DOM / aria attribute, and instead rely on the
<scott> browser css/js to help do this
<pkra> custom elements
Jacques: the real-world example is a custom control that just works, and using the same widget with differing orientations on different pages. Might need a CSS script to control the different orientations
keithamus: not so much about changes during page interaction, it's about how an author is reasonably able to handle the timing. E.g., during the startup/instantiation of element, figure out the orientation then (but this is complicated). HTML, and perhaps unrelated JS that is unaware of mutations, can further complicate this
jamesn: we need some definitive use cases written down to progress this. Any volunteers to flesh this out?
Matt_King: I hope this discussion gets added to the issue
Expectations for aria-hidden and focused elements
scott: was waiting for people to make definitive decisions (on behavior after they made comments)
Daniel: my company is no longer participating in the W3C. This was a worthwhile experience, thank you to James Nurthen/Valerie, great work. Wanted to say goodbye, was an honor to be part of this group.
… Mario as well is leaving. Greetings from him as well