Meeting minutes
New Issue Triage
JN: Just 2 new issues
… First, I am hessitant to document something in the ARIA spec.
Valerie: It has agenda
JN: You can talk about it next week
JN: I am off on sabatical for the next month, I'll be back early February
Computed role for role="treegrid" there is a PR for that
New PR Triage
JN: There are a few. The first is I added a changelog for ARIA 1.3 in prep for publishing
… It's a commit log from before the 1.3 changes started, then took the 1.2 commits and checked if they were common
… Unfortunately tihs is not automatic as the commits in to the stable branch are cherry picks
… Then I filtered out what I thought it's editorial
… I am asking people to look if everything in there is necessary there
… I will be merging it this week
JC: You can assign me to that one
JN: I used the RS Changelog stuff but I just copied it over to our repo
JN: The next one is to revert the association list stuff. Do we agree we want to revert this association? We can still put in something in the future, but probably not a good idea for FPWD
JC: I need to review this one
Scott: Would we be removing this from the changelog?
JN: It would be good, I guess we'll merge the other one first
JC: I added the comment to that particular line in #2096
JN: Next one sounds like an editors thing
JN: Next one was created by Matt, we need some reviewers for this
JN: Adam and Rahim will review this
JN: Next is the treegrid role. Any reason we can't merge this?
JC: If you don't mind assigning me too
Valerie: Assign me, I'll merge when done
JN: Another about trees, needs some reviewers. Same people would be preferred.
JN: Next -- we need James Craig to review + implementation tests
JC: This is the value false is the same
Scott: We discussed a couple of weeks ago. This is aria-hidden="False" doing anything. IF we wnat something to happen probably that'd need to be a new value
JC: I don't want to merge this until tests pass I'll use the review to flag things specially on the empty check box
Rahim: Is MDN and similar updated when things like these are merged?
Valerie: We should probably add a check to make sure we at least keep track of these things
WPT Open PRs
JC: I think these are being addressed, thank you Rahim
JC: Alternate spelling for labelledby (one or two ls)
… It's been around forever, not sure what the state was. Thanks Rahimn for writing these tests
… Browsers are doing different things, no need to discuss this right now, but interesting to see these interoperability issues
BG: Is this used a lot?
JC: Not a great figure but still relevant
JC: I think we should tackle this like if there are two the first should win
Deep Dive planning
JN: No Deep Dive for next week. If anyone has anything please propose something
Reviewers: Fixed handling of surrounding whitespace for CSS pseudo elements, inline and block level elements, and embedded widgets.
JN: We need to get this reviewed. JC and Aron especially as you are implementers
BG: It's holding us up
JN: We need to get AccName to CR
JN: I was re-requested review because there were some unresolved conflicts which I think is fixed now
BG: Yes, these are corrected
Valerie: I sent a ping to Aron
JC: I think I never got back to it because my comment from Dec 2022 does not seem addressed
… Line 479
… "Spacing" is ambiguous.
JN: There is a link to the definition of whitespace
JC: We may resolve this if we say whitespace
… And also whitespace is merely text, I don't think it's ready yet
BG: I don't understand. When you say whitespace is textual content, I'm thinking of printed characters. Whitespace isn't something you can read
JC: That's one clarification that needs to happen
… I'll try to review and add additional comments. I'll provide a suggested change. I think we have now ASCII whitespace definition
BG: Any clarifications are welcome
Valerie: Aron took a look and left a comment with a question
BG: I need to check it, it was a long time ago when I last checked
Valerie: Are there tests for this?
JC: I and Rahim wrote soome tests for the pseudos but it was difficult because of the whitespace issues
Status update: aria-controls spec update
JN: Where are we with this?
Scot: I am not really sure. I am not sure if it's worth doing anything at this point
JN: I kind of lean towards that as well
Scott: Aria-details is for content that provides more details, whereas aria-controls indicates which interactive elements modify that in particular. I don't really know what we would be adding if we force that and what we would lose if we don't have it
JN: Is it even necessary for combo boxes?
Scott: Good questions
JC: I'd be hessitant to change anything about existing specs when testability is not there yet
… That would lead towards more divergence
… Aria-controls has more potential that has still not been realized
… Instead of closing, we can mark it as "blocked for testability" or similar
… Maybe this year we could make some progress on testing these things
JN: I think we are so far away from being able to test that in AT, which is where the problem is ...
… If itis not doing anything useful, why don't we deprecate it
JC: I know there was a previous iteration on combo boxes that relied on the controls relationships instead of in active descendents
JN: I'd agree with that. We would need to fully test it in all places where we think it's useful
JN: But deprecating if something works in at least one implementations it's more likely to break that one implementation
JC: I do recall it was used in the past
JN: Then we should not deprecate it becuase it seems it's used somewhere for combo boxes
Rahim: Isn't this also used in other widgets such as tabs or disclosures?
JN: The thing is whether it does something useful
Scott: Not really
JN: Seems like busy work for authors instead of being useful
Scott: If we know where to use it it could serve a purpose
Adam: It's good for authors to build up the programatic associations
JC: I don't think it meets the bar that we've had in the past for deprecating stuff
… Past deprecated features where weird APIs, this one is not particularly weird and is already used
Scott: aria-details was far more descriptive than aria-controls. Feedback suggests that we have not done enough to communicate purpose of aria-controls
… We can either close this or further editorialize the spec with further descriptions of where this works
JN: Does this make aria-controls better or not?
Scott: I'm fine with either direction: closing it or doing some mor wordsmithing
JN: If it makes the spec better we should probably do it
Valerie: Let's update the title to "editorial"
Scott: I'll write some additional notes in the issue
JN: Thank you
Web devs attempt to nest headings; what to do?
JC: With this code example, I'm not sure what should be exposed
JN: What happens in HTML if you have an h3 and an h2 inside that
Scott: You get an empty h2 and then an h3 with whatever text you had
JC: So it treats it like a malformed element continaution
Scott: Some AT may also ignore these empty constructs
Melanie: IF you pull up the VO rotor you'll see h2 and h3 with the text
<Rahim> I believe this is described in the "in body" insertion mode in the HTML spec: https://
JC: It seems it is concatenating then. HTMLO parsing works but the platform does not
… IF it matches HTML parsing then it may make sense evey if it's more difficult form an implementation perspective
Scott: Do we wnat to clearly scope it for just headings? IT could easily be extended to paragraphs and other structures
JN: What's currently exposed with this markup?
JC: It'd depend on the engines
Adam: IN Chrome I got what Melanie was saying
JN: Do we need to do anything with this? It's not what they wanted but they coded it wrong
JC: We should have consistency
JN: This doesn't sound great for the users but you can't look at everybody's wrong markup and try to fix it
JC: But now that we've found this, we should do something. We should not write interop test if the spec is not clear on this
Scott: With a similar code, I can tell that using JAWS only the heading level 4 is exposed. With narrator aria-level 2 is exposed and the nested heading is not exposed. Different screen readers yielddifferent experiences
BG: I would say not to nest headings. If we qualify then we are implcitly saying it's OK to do so
JC: We could do the two things. This should not be done but if you do here's what should happen
JC: Then we should write some test. Tihs is a multi nesting thing. We can make assumptions as to which of this are. We'd still be at the browser level, we still cannot test AT specifically
Adam: I'll take that WPT work
JC: No need to open a specific interop accessibility issue, just link the PR to this issue and use the "do not merge yet" label
Melanie: Do we have and SC that would support this, for example 1.3.1?
… I think the HTML element should take precedence
JC: I agree with this being an approach, but there's currently nothin in the spec
… The div with the role of heading does not conflict with the HTML h2
… There is not an author error in any spec as far as I can tell
… IF we think that's an author error ,we sshould clarify it in the spec
Scott: With Chrome and MSAA2 the three headings are exposed. With UIA they are not exposed
Adam: I think there was a typo in the issue comment
JC: Yes, I'll correct it