Meeting minutes
present_
<spectranaut_> scribe?
New Issue Triage
spectranaut_: editorial issue. Daniel responded with respec issue
adam: just wanted to connect the dots
jcraig: I'll add a note regarding contrast modes
jnurthen: let's add it for editors' meetins
spectranaut_: aria 2132
jnurthen: can we ask Laurence?
scotto: I'll leave a comment.
spectranaut_: next aria 2129
… we looked at this last week.
… aria 2127. We have 2 PRs landed without author tests.
… once we have tests, we can make PRs on the validator repos.
… these are good first issues.
… can someone take them on?
Adam_Page: I can take one.
adrian: what are the technical requirements?
spectranaut_: Java.
jcraig: happy to help set things up
adrian: I can take the other.
New PR Triage
spectranaut_: html-aam 533 about hidden elements
scotto: this closes an older issue.
… from last week's discussion
… hidden labels in html cannot work because they're not in the accessibility tree.
… this PR clarifies this.
… not just label but table caption and legend fieldset
… do we want to adjust how the name calculation works?
… it might stop the algorithm too early.
… e.g., Firefox will pick up a title from the input. I feel that's right.
spectranaut_: Adam_Page made some tests?
Adam_Page: no, but I'll take a look again.
… I'll review
jcraig: I'll also review.
scotto: I didn't make WPT tests because I wasn't sure what we want to assert.
WPT Open PRs
spectranaut_: sarah wanted to do a deep dive on aria 1119. but let's wait until we can schedule with her
Deep Dive planning
Upcoming Agenda - CSUN Week
<scotto> no csun for me
<aardrian> I will be at CSUNATC
<Adam_Page> I’m going to CSUN
spectranaut_: please let us know if you're going to CSUN so we know if we should cancel.
<katez> not going
<giacomo-petri> no CSUN this year
<Summer> not attending
jnurthen: let's keep the meeting.
Consider providing a way for authors to customize the announcement of state
<spectranaut_> w3c/
giacomo: while working on the PR, I realized that there are two attributes doing similar things
… but right now the spec only deals with one of them
… both override the default semantics of the element
Matt_King: I didn't understand the question on rowindex etc
… can you explain what a single value should mean to do both
giacomo-petri: we need aria-valuetext to change the default value of switch or progress bar
… this seems similar to the grid situation
Matt_King: row and col index text need to be specified together
… we chose not to use valuetext because they can be on the same cell.
jnurthen: that's my recollection as well.
… regarding switch. is there a case where we need to know what the other value is?
… if we have one thing, we'd need to know both.
giacomo-petri: right, could be. progress bar is similar - percentage or small/medium/...
… this would be a good feature but perhaps it's not needed.
jnurthen: I think I agree
… I feel that even if we added it, AT wouldn't use it.
… I'd prefer to wait for AT to demand the other value.
giacomo-petri: the other problem with the switch role: if value text is specified, then we also require now value to be specified
… that doesn't make sense for a switch.
… hence my proposal
Matt_King: so aria-valuetext on a switch, you wouldn't add checked/unchecked?
giacomo-petri: that's the question. It seems it's always an active state.
Matt_King: that's the reason why it requires value-now.
… we had a lot of discussions in APG about this
… e.g., day of the week on a slider.
… valueNow could be 1/7, 2/7 etc
but that doesn't make sense and adds no value for the user.
… and it works fine anyway.
… we've discussed raising an issue here. But I don't want to expand the PR.
… it seems like you wouldn't need to require aria-checked.
<Zakim> scotto, you wanted to react to giacomo-petri
scotto: I like the idea of using aria-valuetext because I like the idea. But it's not even a state. It seems more like a new attribute.
… and it's not just for switch.
<Zakim> jamesn, you wanted to agree with Matt that I think we could remove that requriement and to ask if switch in APIs required a checked attribute
jnurthen: one of the complications is HTML's definition of value and how people are using it in the real world.
… checkbox's values is never what anybody talks about.
… I agree with Matt that we should remove the requirement for value-now
… that would also allow us potentially to use it here if we end up wanting to.
… I wonder if accessibility APIs need it.
jcraig: does the ARIA taxonomy require this as well?
… I think it does.
jnurthen: right. But we could also change that.
jcraig: feels like one of these features where we should tag it for privacy
… if it's switched around
jnurthen: feels like any form would fall for the same
spectranaut_: it seems we agree valuetext is not the right thing
<mario> I agree with th use of statetext
Matt_King: random guess: state-text. but still leaves the questions.
scotto: for roledescription we don't remove the role either?
Matt_King: true because it's critical.
scotto: right but I think you still need the initial state. otherwise which maps to which.
Matt_King: is that the same argument as with value-now?
… oh, when you're processing the "actual" value?
scotto: yeah. value-now is what a human understands but you still need to be able to fallback to the underlying actionable state of the component.
… otherwise it'll be just "value" without any actual state.
<siri_> we don't use pressed attribute if the label changes like play/pause
Matt_King: the JS will need to know the value, but will AT need to? It seems like a switch, e.g., swapping cm and inches, won't need to expose that.
mario: for switch checked/not-checked but it's not easy to understand why/how it maps to red/green.
jcraig: I still don't feel why we couldn't re-use value-text here.
… we know what to announce based on value-now but what we announce would be value-text.
<Zakim> jcraig, you wanted to ask why not have aria-valuetext require one of [ aria-valuenow | aria-checked | n… ]
jcraig: seems easier to expect value-text to require things as needed.
Matt_King: so you'd expect an event from value-text change?
jcraig: I could see implementations work either way
… but requiring checked makes sense, e.g., for styling.
giacomo-petri: sometimes you don't have green/red - e.g., cm vs inches is "always on".
… I see that it can be problematic from a development point of view.
… it's not true/false but a choice.
mario: but what is the change? it's always checked?
Matt_King: I think a cleaner implementation of aria-checked isn't possible?
… could you not style based on the value-text text?
spectranaut_: I think so but it wouldn't apply to all switches.
Matt_King: but then you'd have to document checked matching a specific style.
<jcraig> https://
jcraig: I had written something that was trying to match HTML phrasing
… for the cm vs inches. what would we do in HTML?
… that should affect what we should do in ARIA
<Zakim> jamesn, you wanted to ask how we envision this tying in with the native switch efforts going on
<jamesn> https://
jamesn: the blog post mentions checked as attribute. but it seems like thumb and track will be standardized for similar purposes.
… I don't know how we will tie that together.
<jcraig> .sliding-track::before {
<jcraig> content: "ON" / "";
<jcraig> left: -40px;
<jcraig> }
<jcraig> .sliding-track::after {
<jcraig> content: "OFF" / "";
<jcraig> right: 0;
<jcraig> }
jcraig: [pasted the example]
… not sure what the empty string should mean.
… but we may not need this new feature if HTML provides it.
jnurthen: feels like accessibility wasn't entirely thought through yet.
scotto: that's why I raised it.
… anyone can change it and it no longer matches checked/no-checked.
<aardrian> Not merged yet: https://
jcraig: but it seems like the feature seems to already support it?
scotto: implementation goes off of role switch with checked/unchecked state.
… not from css content.
<jcraig> content: "label" / "alt";
scotto: that's just how it's visually rendered
… if you drop the alt, you'd sometimes get "on on"
jcraig: but if label/alt is supported, it feels like an implementation bug.
jnurthen: one is the before and the after on the track - how do you connect that in to checked/unchecked?
jcraig: right.
… thanks for clarifying.
spectranaut_: we're at the hour. do we have enough to move a bit forward?
mario: we have to battle through the HTML accessibility
scotto: they're working through the pseudo content
jnurthen: agreed and they should know that they shouldn't.
adrian: my tests were something like "accname on or off switch"
jcraig: accname included both before/after.
… we might have to modify the PRs and WPTs.
scotto: the same with Open UI. People kept doing on/off whichever way they wanted. But everything pulled it in since it's name from content.
spectranaut_: we're at the hour.
… there's more to discuss.
jcraig: thanks again to scott for raising this.
<aardrian> My announcement tests with TP 185: https://
scotto: [...]