Meeting minutes
New Issue Triage
jamesn: aria #2152: my initial understanding is that this is not the same thing as aria-required. Requested in the past for checkboxes
mario_Batusic: Not totally the same, but required at least once (or more)
scotto: Allowing aria-required to be used at group level would not solve this use case; would trickle down, every element is exposed. We've had this discussion multiple times before citing similar examples; level of effort to make this work is roughly assigning required attributes on elements
jamesn: would echo what Scott said; to make it meaningful for non-SR users, need to have visible text explaining that you must fill in one of the things (use aria-describedby in this case anyway)
mario_Batusic: can use an asterisk
jamesn: can this be closed as "not going to implement"?
mario_Batusic: would appreciate setting aria-required on the group
jamesn: if you'd like to write up an explainer, you can do that. aria-required may not be the right attribute
scotto: it's worth reviewing other closed issues that are about this with rationale on why we did not go forward with this
spectranaut_: in the editor's meeting, we talked about adding labels with aria attributes so it's easy to find issues related to an attribute (e.g., searching for "aria-required"). It would be nice to search all closed issues about aria-required, wanted to let the ARIA WG know this and we should add the label to this issue
Francis_Storr: would agree with this (aria #2152), I like this idea on supplying aria-required
… could be the element at the group level (not individual form controls) that could be in an invalid state
jamesn: the idea of a required checkbox doesn't make sense to me
<scotto> openui/
New PR Triage
jamesn: for accname #234, need to create tests for this
Rahim: I can look into it
Rahim: James C. recently rewrote white space utility function for WPT testing, good time to test
… white space utility function for computing label*
scotto: html-aam #537: would disagree with HTML definition
jamesn: for accname #233: similar to #234 and white space issue
Rahim: I can take this one as well
jamesn: html-aam #538 still needs more work before merge, over to Rahim as well
… relates to <meter> values and associated states
jcraig: also look into what a11y notifications are being sent
No Meeting April 11, 2024
jamesn: I will cancel the calendar entry for Apr 11; James N/Val on vacation
WPT Open PRs
jamesn: James C., any that you want people to review?
jcraig: if anybody wants to review, and can review, please jump on it
Deep Dive planning
jamesn: list of deep dive topics is building up again
sarah_h: yes, happy to schedule something. I'll be out mid April but next week works
aria-keyshortcuts needs attention - should we schedule co-meeting?
jamesn: this is a question for the WG. He offered to do a joint call to discuss but James C. said the issue is clear enough and don't need a joint call
jcraig: if Addison is willing to write a PR that fixes it, that would be the most efficient way to do it
… if a meeting is preferred to coach one of us (ARIA WG) to write a PR, we can do that. Feedback seems reasonable
jcraig: Google is the driver for this, and Google docs is one of the largest users of this, would prefer if someone from that team is there. But if Addison writes the PR, don't need Google involvement
jamesn: don't feel that much other stuff than editorial needs to change, i.e., address localization/language concerns
Discourage authors from using role=none/presentation on table cells (and maybe list items)
jamesn: we may have spoken about this (perhaps in triage). I wanted to talk about this more...what do folks think about this?
scotto: for aria #2135, I don't think it's bad to have authoring guidance but don't think this is the right place to put it. I'm thinking of situations where people need to put presentation role on a native cell so they can add additional custom cells inside of it, to fix table markup (because native markup can't be changed). Absolutely agree with the sentiment here , but ARIA may not be the right place for this
Matt_King: trying to parse what Scott just said; I was going to say it almost feels like anytime a role is a required a11y child...I'm trying to think of a situation where you end up with a list item in a list that doesn't have a role, what is it? This may always result in an invalid a11y tree, how would it not?
scotto: I'm describing a situation where someone has created a table but a column of the table is exposed as two separate columns so they put role="none" on native HTML elements (which is what this issue is about); someone then has added two <div>s to the HTML elements and put the necessary roles on those so the native elements' role has been suppressed, they've re-added the necessary roles to re-create the table markup as intended
sarah_h: I have another example: when we were making our date picker, we had native <table> markup; at one point it was working better with "gridcell" but pros and cons to both approaches. In another example, we had fixed headers on a table; used CSS to fix headers but had to use role="presentation" on native elements. I can see an author warning to ensure correct usage, but a MUST NOT/SHOULD NOT author guidance may be warranted
CoryJoseph: I just ran into a case where this is happening on a list item and it was a breaking issue; it made the content disappear from the a11y tree (in a bad way). Similar to the example that Sarah just described but implementation broke everything. I'm leaning towards Scott's opinion that this feels like a hack to fix something in table structure
jamesn: Would echo Scott/Sarah's thoughts; we needed this to work around various issues in the past but I agree it shouldn't be a prohibition. If done, you must ensure robust testing and make sure everything works
<scotto> example of what i was talking about - https://
Matt_King: Is there a way to say something such as: if you override the role of a required a11y child then you MUST do something. What would be the wording for these types of scenarios?
jamesn: Should we add warning language for this?
scotto: I'm not against adding warning language at all; I can't think of how it would be written. Sounds like an authoring practices guide topic
Matt_King: We have this in the APG and provide some forms of guidance; there's space to add real guidance on the damage it could do and things one should be careful about
jamesn: We could put a section in ARIA spec section 5.2.6; this could be the place to put it
… should we file a child APG issue?
Matt_King: OK (you can assign aria #2135 to me) so long as there is a comment in the issue to clarify the assignment
Clarify whether author errors in "required accessibility parent/child" (formerly "required context") should be handled by UA
spectranaut_: it was put on the agenda a long time ago; James C. found the spec reference he was looking for talking about orphaned roles where required a11y parent isn't present. Spec says you shouldn't surface the role in this situation
jcraig: A couple reasons I haven't closed this: I haven't had a chance to review html-aam and also, this is a good test case to determine if implementation is having difficulty with this, this is a good example where we can roll the normative requirement back. Mozilla was the filer for this issue and had some of the best support, but there are different failures across engines (Gecko, Chrome)
… leave this one open and assign to me
scotto: there are instances in html-aam where these things are called out. I recall filings bugs, e.g., <summary> elements put inside <details> element (e.g., Gecko exposed those as buttons but they didn't do anything). This may be one reason why they were making cleanups for similar issues
jcraig: There was another one that came up similar to this; if you intersperse a <div> in between a list or list item, the list item still gets a bullet. In this scenario, we need an exception to ignore the role
… I haven't dug through the browser comparisons on whether browsers are rendering the bullet
… if the UAs are rendering it, we should make what they're rendering accessible
jamesn: Could end up with a 5 item list made up of 5 individual lists
jcraig: recommending that we don't hide the list semantics, align with how it's visually rendered
scotto: Worth bringing up to CSS folks, they may not have considered this edge case
… I can file the CSS issue for this
Matt_King: A question: after I create the issue for aria #2135; James N. recommends waiting for APG response on next steps