Are there use cases for logical properties in aria-orientation?

[pkra]

Currently, aria-orientation allows horizontal and vertical.

Are there use cases for logical properties (i.e. inline and block) when it comes to orientation?

[scottaohara]

inline and block would align with how focusgroup is handling directionality.

[css-meeting-bot]

The ARIA Working Group just discussed Are there use cases for logical properties in aria-orientation?.

The full IRC log of that discussion

<Zakim> agendum 4 -- [Are there use cases for logical properties in aria-orientation?](https://github.com//issues/2750) -- taken up [from jamesn]
<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.
<Rahim> jamesn: we are unsure what this issue means (e.g., `inline`, `block` values) for `aria-orientation`
<Rahim> scott: using `inline` for left/right navigation, and `block` for vertical navigation. Just different terminology
<jcraig> q+
<jamesn> q_
<jamesn> q+
<Rahim> 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
<jamesn> Ack jc
<pkra> q+
<Rahim> 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
<Jacques> q+
<Rahim> ...I would like to understand the context; is there a change we can review related to this?
<Rahim> scott: was only just noting that it wasn't an uncommon thing out of left field
<Jacques> q-
<Rahim> 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
<Rahim> 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
<jamesn> Ack me
<pkra> ack me
<jcraig> q+
<Rahim> ...`focusgroup` is another good example of this (directionality)
<Rahim> 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.
<Rahim> ...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?
<jcraig> q+ to ask if there are any related renderings that change when the writing style switches to vertical... For example, do sliders change to vertical?
<Jacques> inline/block is roughly the same though.
<Rahim> ...should look at applying directionality on a selective basis perhaps
<keithamus> ```
<keithamus> data:text/html,<select><option>One</option><option>Two</option></select><style>*{writing-mode:vertical-rl}</style>
<keithamus> ```
<Jacques> https://open-ui.org/components/scoped-focusgroup.explainer/
<Rahim> 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
<jcraig> ack me
<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?
<Rahim> keithamus: see `input type="range"`example I posted in IRC
<Rahim> jcraig: maybe the mapping is tied into HTML/CSS AAM which changes the `aria-orientation` to vertical
<Rahim> Matt_King: are you suggesting that the browser does this automatically when the browser maps a11y attributes in the a11y tree?
<Jacques> q+
<Rahim> jcraig: may be confusing to authors to change the meaning of these `aria-orientation` attribute values
<keithamus> q+
<jamesn> Ack ja
<Rahim> jamesn: the control itself would have to (a custom scripted control) would have to know the writing mode
<jcraig> q+ to discuss the mappings in https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology
<Matt_King> q+
<Rahim> Jacques: if author noted `horizontal, how does this map to screen readers? Specifying `inline` or `block` allows browser to compute directionality
<jamesn> Ack keithamus
<jamesn> q+
<Rahim> 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 to have these terms block/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
<Rahim> logical properties)
<Rahim> 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`?
<jamesn> Ack jc
<Zakim> jcraig, you wanted to discuss the mappings in https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology
<Rahim> 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)
<Rahim> ...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 examples, the value of `aria-orientation` changes (via mapping and browser calculation)
<Rahim> ...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)
<jamesn> agenda?
<jamesn> Ack Matt_King
<Rahim> 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
<Rahim> where engine has implementation and author is listening for keys and gets the wrong one
<jcraig> q+
<jamesn> q-
<jamesn> Ack jc
<Rahim> 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
<jcraig> q+ to discuss examples like a circular slider
<jamesn> Ack jc
<Zakim> jcraig, you wanted to discuss examples like a circular slider
<Rahim> 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
<Rahim> Matt_King: Right/Up and Left/Down do the same thing in this scenario
<Rahim> Matt_King: Highlights different in LTR vs RTL languages (right is increase/increment in LTR languages)
<Jacques> q+
<jamesn> Ack Jacques
<scott> q+
<Rahim> 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
<scott> q-
<Rahim> jcraig: because you're using a toolbar as a managed widget, then the controller for that view should update `aria-orientation` property
<Rahim> Matt_King: big question is who is responsible for that; is that the author?
<keithamus> q+
<Jacques> q+
<Rahim> 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
<Jacques> q-
<Rahim> Matt_King: in a toolbar, you often only want to use one set of arrow keys (due to drop-down, submenus or combobox implementations)
<Rahim> 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
<jcraig> q+ to ask if there's IDL precedent for anything like this.
<Jacques> q+
<jamesn> Zakim, close the queue
<Zakim> ok, jamesn, the speaker queue is closed
<jamesn> Ack keithamus
<scott> q+
<Rahim> 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?
<Rahim> keithamus: for a custom widget, I 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
<Rahim> ..when the attribute is set, no way to know writing mode
<jamesn> Ack jcraig
<Zakim> jcraig, you wanted to ask if there's IDL precedent for anything like this.
<jamesn> agenda?
<scott> q-
<Rahim> 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)
<jamesn> Ack Jacques
<Rahim> ...in such cases, the default value could either come from the browser or author (e.g., custom slider)
<Rahim> 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
<keithamus> q+
<pkra> custom elements
<Rahim> ...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
<Rahim> 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
<Rahim> jamesn: we need some definitive use cases written down to progress this. Any volunteers to flesh this out?
<Rahim> Matt_King: I hope this discussion gets added to the issue
<Rahim> zakim, next item

[cookiecrook]

Related to the increment/decrement events in:
https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology

#2759 does raise a good challenge for the vertical orientation challenge though.