Meeting minutes
New PR Triage
Sarah: this topic is on the agenda
New Issue Triage
Peter: that is from the editor's meeting
jamesn: from the feedback from ARIA IDL work
Rahim: pretty sure the answer is no
Rahim: but maybe aria-disabled/hidden/expanded should work like html boolean attributes like "disabled"
Rahim: but maybe we should talk about it
jamesn: I'll agenda it
front-endian-jane: I can put a PR with what I think should be the change and we can talk about it then
WPT Open PRs
web-platform-tests/
jcraig: More opinions from other browser engineers on https://
jcraig: web-platform-tests/
keithamus: There needs to be some changes, we should have a webdriver way to say "wait for this promise to resolve" before considering the crash test a crash
jcraig: sounds non blocking, we should look into that
jcraig: there are some old ones from giacomo and scott, please review or re-review
rahim: I wanted to ask if we should document the behavior of tests that don't apply for a particular browser.... because someone would see that and see firefox doesn't crash, even though the test didn't really run
jcraig: add a readme to the directory?
keithamus: if we had an issue describing this we could point to the issue
keithamus: I'll file an issue
jcraig: put the issue in the accessibility interop repo
agenda, next item
TPAC planning
jamesn: will someone from apple lead this?
jcraig: its tenative, but yes if so
jcraig: I think we need someone from the openusd, but not sure they will make it
jcraig: openusd is a model file format where we are hoping to get accessibility properties in there, the first set to ship is label description and priority
jcraig: there are parallels to SVG
jcraig: in that SVG can have an alt associated with it, remotely linked, embedded accessibility information in the file.
jamesn: even if it is a brief overview of what is going on, it would be useful to have
jcraig: if nothing else I can give the overview
jamesn: maybe appropriate for a slightly wider APA group discussion?
jamesn: maybe broader than ARIA?
jamesn: unless we just want to get in a nitty gritty technical detail, this would be the group, but if you wanted broad strokes/brainstorming it could be helpful
jcraig: maybe not joint -- but you and that APA chairs could not schedule competing times, so they could attend if they were interested?
The above discussion was about: w3c/
jcraig: do we want one session on accessibility interop? maybe we need individual sessions on separate topics under this
jcraig: like the accessibility property bag that jamie teh and rahim and working on, and the AAM tests val is working on
jcraig: I was hoping to have time to discuss which of this bullet list we wanted to separate out into separate meetings
matt_king: there is a lot to cover just on the AT topic
jcraig: maybe we do keep this one just about AT interop as you filed it
jcraig: lola said there is a breakout group on tuesday
matt_king: I filled two, one for daniel, about a high level discussion of pulling all the pieces together. It might be good to have some of these other topics covered for the group before the higher level discussion
Daniel: it doesn't have to be one or the other, we could have both
Daniel: I haven't had time to put my thoughts in the issue, I thought of this as a joint meeting, to know what everyone is doing in terms of accessibility testing
jcraig: I'll file another issue as a discussion of property bag of web driver
matt_king: I think I want a full hour on AT testing
jamesn: what is your goal for the output of this?
matt_king: We are moving away from incubation and towards formalizing the ARIA-AT work. But "which work"
jcraig: lets leave this one, call it accessibility interop -- cover all the pieces then deep dive into ARIA-AT.
jcraig: with pointers to all the others
spectranaut_: I'll make an update on Acacia/AAM tests
matt_king: We should organize the sessions in a way that helps people go from one rendering stack to the other end of the rendering stack, and all the work we are doing to harmonize all this work together. The bigger problem is that we aren't harmonized and we don't have a comprehensive strategy
jamesn: Matt, can you put your thoughts into one of these items
[aria-valuenow]: default to native value when one exists
sarah: quick over view, role=input on a input type text
sarah: the input has a native value, but you are required to put aria-valuenow, it seems unnecessary, it can cause problems, this can conflict in terms of timing -- the value is updated, but aria-valuenow is update a cycle later
sarah: I wanted to make it clear the default value of aria-valuenow should be the native value where it exists
sarah: better fall back for aria-valuenow than zero when native value exists
jcraig: great, I agree conceptually with the change. I'll review. A handful of things...
sarah: it is draft because it's not complete yet, more sections need to be added, but you can review what is there
jcraig: we should reference the host language generally and use html as the example
Matt_King: I haven't looked at the PR, but I'm so happy you are doing this!
Matt_King: does this involve changes to aria-valuenow description
sarah: no, the value calculation for roles that use it would change
jcraig: it is in the description prose of spinbutton..... but should it be moved to the aria-valuenow discussion?
Matt_King: there are a bunch of other circumstances, where not requiring aria-valuenow is a problem. like sliders, where aria-valuetext is specified, aria-valuenow should be added
Matt_King: and it makes it much more verbose when both aria-valuetext and aria-valuenoe are included
sarah: yeah, there is an issue open for value calculation, value calculation wouldn't solve this particular issue
sarah: matt I fully agree, but I don't want to expand the scope of this
sarah: I'm actually make this pretty scoped, the number of elements that have native values that you can do this for is quite small, see aria-html
Jacques: my question is: for spinbutton, that makes sense... but what else?
sarah: the things that can have aria-value now are limited, so that is the gaurdrails
sarah: but if you put a progressbar on an input, I don't see a problem with the value gettinga default
sarah: (reads the open question)
sarah: One open question: if the native value is set to something that cannot be evaluated as a number such as "5 cm", should we say that authors MUST define aria-valuenow, or should we say that the value should be treated as aria-valuetext?
jamesn: because of the ability for this to happen, what would be the harm, if we always did aria-valuetext instead of aria-valuenow
sarah: I'm curious to hear what jcraig has to say, voiceover doesn't read valuetext at all
jcraig: I think that is clearly a bug
sarah: generally it reads the percent, not the aria-valuenow number
jcraig: every control is different, for a spin button, I think it reads the value.... but maybe there is a combo of native control and aria and it doesn't do the expected thing... if you have that monstrosity handy please link me....
Jacques: I was going to say, for UIA, and patterns that support range, the API takes in a number. IF the number is not available... I'm not sure if there is a range value that doesn't have a value and supplies text instead that would be difficult for narrater
Matt_King: so james, we have 3 slider examples with robust testing in the ARIA-AT reports. So sarah, did you explain what happens today if someone puts "5cm" in aria-valuenow
sarah: I made this issue and PR two weeks ago and I would have to re-tests
Matt_King: I wonder if the way browsers are doing that right now today, what do they expose. I think we would want that to work the same way, it seems like a good idea, if there is a text string in the native value and it does what you propose, it is exposed as value text, if someone did the samething with valuenow, it would be exposed as valuetext
sarah: that one I might hand off to Jacques... that seems more like, from the browser implementation perspective, that is a reasonablish thing to do
Jacques: I think we parse it as a number, if we can't parse it as a number, we throw it away
Jacques: we expose the value attribute as well as the range attribute. Tools like narrator are looking at the number
<Zakim> jcraig, you wanted to say not seeing a spinbutton test in ARIA-AT, Did Matt mean Slider?
jcraig: I'll gen more test cases for spinbutton
sarah: I heard general suppport....? yes fall back to value text?
(general agreements)
Matt_King: (didn't catch but he had a concern)
sarah: I think I'm solving a different, specific use case
<jamesn> +1 to sarah
<Zakim> jcraig, you wanted to discuss cloaking...
jcraig: this reminds me of a few years ago someone brought up that you can use one of these aria properties to lie to the user agent, and actually they were using javascript, this is one of the properties where you can mask or cloak what is visuallly rendered vs what is exposed to the AT
jamesn: isn't this all of ARIA
jcraig: the reason i thought of this as the scenario that sarah mentioned.. .do you want to suppress the value based on valuetext... the idea that we should prioritize value text in some sort of scenario
jamesn: I've seen things like slider where percentage value make not sense
<Jacques> need to drop a little early, thanks all!
jamesn: there are valid use cases where we really need to overwrite the value with valuetext