– DRAFT –
ARIA WG

New Issue Triage

<spectranaut_> Rahim: From james previous comment, maybe we should consider similar semantics to ARIA

<spectranaut_> Adam_Page: I have a wpt test for this I'm working on

spectranaut_: May have to be talked in the ARIA WG, will be added to agenda
… will be great to discuss once we have tests

New PR Triage

spectranaut_: aria #2102, nothing that the ARIA WG needs to look at

dmontalvo: good to merge

spectranaut_: Will look at this after the meeting

WPT Open PRs

Deep Dive planning - whitespace for CSS pseudo elements?

spectranaut_: James C. still has concerns regarding whitespace on pseudo elements; if James joins later, we can return to this item. Should be resolved since it's been open for awhile and blocking other issues

if not, can schedule this deepdive for next week

Call for consensus for first public working draft of 1.3

<Adam_Page> +1

spectranaut_: Have been talking about this; PRs open for editing change log. This is the official call for consensus. If you approve, type +1 in IRC

<spectranaut_> +1

<Francis_Storr> +1

<giacomo-petri> +1

+1

<scotto> +1

<sarah_h> +1

<spectranaut_> Matt_King +1

<siri> +1

Align ARIAMixin with changes in HTML

spectranaut_: Have 2 items on the agenda related to ARIAMixin; not something closely followed by many in ARIA WG. This is related to HTML spec (Anna, Dominic trying to correct inconsistencies between ARIA and HTML specs)
… we can ask Alice B. to review. Does anyone else want to take a look?

keithamus: can review it due to personal interest as it relates to ARIAMixin. Worth having a second opinion besides me

Rahim: please add me as well

spectranaut_: Previously, only James C. followed it closely so great to have others look at it

ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly

spectranaut_: this one is an older issue; lots of comments but most recently, there was a comment from Domenic on opening an issue to discuss fixes. His proposals involve not changing current behaviors. Rahim/Keith if you can take this one as well, thanks
… for html #10037, this one may be challenging to discuss

keithamus: this issue is largely discussing mechanics of HTML spec and how it relates to enumerated attributes (which may not be a big concern for ARIA WG)
… just skipping the html issue, it doesn't look like we can provide significant input

sarah_h: there may be ARIA WG input; can discuss what can allow to be set for ARIA attributes that have enumerated values when you set it programmatically to something invalid/illegal. I'd be interested in talking about this, but not right now

keithamus: I think the tl;dr is that if it's an enumerated attribute, we should specify in HTML spec that it's defined in the ARIA spec. So, we should have some ARIA reference for enumerated attributes that the HTML spec can link against
… the action item may be to specify enumerations for available mappings, then go and make the necessary changes to HTML spec that point to those

spectranaut_: that seems straightforward; can you verify that is the next step?

keithamus: I'll read through the issues and comment

MarioB: am I understanding correctly that we have to set the ARIA attributes/properties to be the same as the HTML analogs?

keithamus: In the HTML spec, enumerated attributes must have known valid values. If the values aren't supplied, our job (ARIA WG) is to supply the values so HTML spec can correctly reference them

Document interop of misspelled aria-labeledby and its conflict resolution

siri: what is the purpose of AriaMixin?

keithamus: Purpose is to allow reflection of ARIA properties via JavaScript; specify attributes without modifying the element

<spectranaut_> rahim: a few items, will we document the alternate spelling, how does this interact with precedence? if it is a synonym, it should behave the same.

<spectranaut_> mario: do we have to reflect that in the spec?

<spectranaut_> rahim: yes

Rahim: I agree that we should document this in the spec; should decide if it's a synonym and how accname precedence works

<spectranaut_> mario: if the browser do it, we should document it

scotto: what is the current behavior that you're reference Rahim? I would think yes as a synonym; for precedence, whatever attribute shows up first in the DOM. E.g., double declarations use only first instance

<spectranaut_> rahim: it looks like aria-labeledby is honored in chrome and safari, many tests fail in firefox, it doesn't recognize it

<spectranaut_> scotto: I misunderstood, I thought there was a preferential treatment, if both as supplied, aria-labelledby with two ls supercedes the other

<spectranaut_> rahim: two ls supercede one l

scotto: my next question is, is the WPT test taking into account which instance of aria-labelledby/labeledby is first? Add tests for swapping order, compare the two
… check to see if it's preferential treatment vs. DOM order

Rahim: will add a couple more tests for this to determine this

Rahim: should this act as a synonym?

scotto: I agree (spelling is hard)

Consider providing a way for authors to customize the announcement of state

spectranaut_: talked about aria #2085 in relation to another issue (didn't we already discuss this?)

scotto: we did talk about this briefly but wasn't in tandem with anything else; may have spun out of 'controls without explicit grouping' discussion but not the same
… the high level (summary) here is this came out of a conversation from OpenUI; efforts took place to spec out a switch control and how people want to use that control vs. how it's currently spec'd to behave. E.g., a toggle for dark/light where visually it's styled as a switch, but the change in state is "choose mode" rather than "on/off", it would be "light/dark"
… now, for controls that toggle between states, must come up with label (accname) where on/off makes sense for that control. For this issue, the idea is that we could modify the way state is announced
… then, could have a control labelled "Theme" and its values/states could be unique without contorting accname
… what do people think of this? We have already have aria-roledescription

MattKing: great description and among the common things we see (mute/unmute, pause/play) and they're looked at as toggles. Usually consider these buttons where the label changes
… the label you have is what will happen if you press the thing, e.g., "play" turns into "pause"
… if you have a button for "dark", it's just a button that cycles through states on activation

scotto: the difference here is that, you're talking about a button that lacks a visible label (but there's an icon that represents the state) and accname changes accordingly. I'm talking about switch control where there is a visible label and the label shows up next to the control; there is a visible text equivalent of what the state is along with the accname (label) of the control. It's just the visible state changing, not the accname

MattKing: I'm wondering if what you're describing is state; is there an a11y advantage to delineating this state
… as opposed to the label that appear on it/next to it

scotto: I understand what you're getting at; this come up in the context of switch controls
… even if someone did add in an accessible name change (e.g., theme: dark, theme: light), you'd still hear "on/off" because someone is using the appropriate element to do this
… want to have a visual label that conveys state, but must contend with the fact that even if it's marked up correctly (visual presentation matches programmatic exposure), will have duplication of state where aria-checked state is announced, and the visible text of the state is also announced
… or would have to aria-hidden=true for visible state which causes discrepancy in what a user hears (with AT) and sees

MattKing: if I'm understanding correctly, the a11y advantage is that it would enable designers to reach for button or switch, rather than forcing folks to use role=button whether it's a switch or not

scotto: yes, that jives with what I'm talking about

MattKing: if that's what we want ARIA to do, that's OK

scotto: unfortunately, some of the rationale behind bringing this up due to contention around something being a switch but role=button is used (and it is considered "wrong"). Risks being pedantic however, would rather reduce disagreement and not be perceived as a roadblock

giacomo-petri: my idea is, as Scott said, there would be a discrepancy between what users see/hear. We've talked about play/pause buttons and off/on states. For example, may need to switch between centimeters/inches; as a switch button, you're forced to activate it to understand the other option. I think it's a good idea to consider these scenarios for equivalent access

siri: we can have role/type as "button"; we already have aria-roledescripton for things like carousel/slides. If we want for state, for example checked, we can provide custom states. Switches can be used in many ways (e.g., on/off) but another example like centimeters/meters, I want to know which one is selected/checked
… maybe here, can we introduce a new attribute which can be customized?

scotto: just want to add here that I'm not unnecessarily trying to recommend we do this because we want people to use switches rather than radio buttons. For the things I'm talking about, radio buttons may be the better choice. I want to make sure that, if there are valid instances, we may want to change the way a state is announced and it's worth discussing whether or not we could do that (not whether it's a good idea or not)
… use cases seem to be rising, want to know what group thinks

sarah_h: similarly, when I first read this issue, this does strike me as addressing the toggle use case
… a sighted user, sees the state changes visually and this is common enough that if we don't allow this, or forcing authors to fight against what is a common UI pattern (or wrangling it into an alternative pattern like radios). Makes sense to me to provide this, trying to fight against common UI patterns may be a losing battle

scotto: the issue I see is that, you could wrangle this into radio buttons; if you make it into a switch, now you have a switch that doesn't behave as such from a keyboard perspective. Yes, it may be programmatically exposed correctly for screen reader users but for sighted keyboard users, frustrated that it doesn't align with expected keyboard operability

MattKing: I've had conversations with content designers/creators, they get confused because it's not super easy (to get right)

sarah_h: wanted to throw out the idea that maybe what we want is specific to switch, and not a general override for state announcements
… if this is specific to switch, perhaps the solution should be specific to just this control/pattern

scotto: what gives me pause is aria-pressed (why have a toggle and a switch?)

MattKing: do we have a way of thinking of localization issues (e.g., aria-roledescription). May get pushback from AT vendors; do we have a requirement that they have custom representation of state and not speak "on/off"

sarah_h: should this be a string, or can it use a visually present elements

Adam_Page: was curious in the examples you've described (E.g., dark/light, yes/no); have folks offered a mixed/indeterminate state and how we might/need to accommodate that. Or perhaps forbid it like the switch control states

MattKing: we do support a partially pressed toggle button

Rahim: like a tri-state button

MattKing: if something is labelled by something (e.g., state) to reduce redundancy on what is read

scotto: maybe we can generally agree if it's something worth exploring; then I and some other folks could work on a draft of what this could look like and have it reviewed by the group

<sarah_h> +1, I think it's worth investigating

MattKing: the one advantage for screen reader users for state, is that you have control of what is announced. That's the difference between embedding it in the label string

spectranaut_: sounds like there is consensus on continuing to explore this

scotto: I'm interested in others' thoughts on this, please add to the issue