Meeting minutes
New PR Triage
jamesn: 2 new PRs
… aria#2590
… some non-standard normative stuff to fix
… PR is editorial
scott: back in the day, this was a spec for *user agents*
… so some of this was implicit
… but I get the feedback and agree
jamesn: these are all the normative statements that don’t have a qualifier
jcraig: did you come across any other “for example”, occurrences?
jamesn: I didn’t search for it
jcraig: I’d like to review
cyns: I agree, I think we were soft-pedaling years ago
jamesn: okay, thank you
jamesn: next one
… aria#2587
… has 2 approving reviewers
cyns: not a complicated one
spectranaut_: there is an open question
Rahim: I had asked Luke to add a link to the standard
… to that part of the HTML spec
jamesn: IDL stuff should be linked by respec automatically
… preview seems good
<Rahim> reflect link in HTML spec: https://
jamesn: I think there’s nothing more to do
Rahim: I’ll answer Luke’s question in GitHub
… the only part of the reflection standardization that he hasn’t worked on is for enumerated attributes
… our ARIA IDL is going to include something like reflectEnumerated, when that lands
… Luke is currently working on that, so once that’s done we’ll incorporate it here
… I’ll follow-up
jamesn: great, then we can merge it
New Issue Triage
jamesn: 7 new issues
… html-aam#590
… no need to discuss
… aria#2589
Matt: normally we use “page tab sequence"
jamesn: anyone want to work on this?
keithamus: the HTML spec has standard language for this
Matt: this is different
jamesn: will mark as good first issue
… next
… aria#2588
… agenda’d for later in the meeting
… skip the next one
… aria#2584
… from giacomo-petri
… there’s some discussion on this
scott: one thing not called out in this
… trying to differentiate form landmark role from general form role
… Joannie had implemented something over in ATK
… a non-landmark version of a form
… to be exposed even if it didn’t have an accname
… #1 not a requirement in HTML, so we removed it from ARIA for parity
… #2 if you want the form exposed as a landmark, you can give it a name
Matt: analagous to <section> and region, right?
scott: yep
cyns: sounds like a won’t fix?
jamesn: yes, I agree
giacomo-petri: yes, I would expect that same naming/role behavior to work the same for form
scott: I don’t know if the form behavior works the same in all browsers
… but remember Joannie doing work in ATK
jamesn: form maps to form role always, according to the html-aam spec
… except bit of “if form has no accessible name, do not expose the element as a landmark”
… I think the behavior is correct, just the spec language is slightly inconsistent between form and section
Matt: should an unnamed form just be a generic?
<aardrian> Agreed that current behavior is good / correct.
jamesn: i think it essentially is
scott: similar to fieldset; it’s a group regardless
… always a group, just is it exposed or not — the AT can decide whether it wants to expose the role
jamesn: I propose we close as a won’t fix
aardrian: +1
jamesn: would someone like to respond in the issue?
Rahim: how does this square with a form that lacks an accname being an authoring error?
Rahim: it’s currently that way in the spec, but after a PR gets merged it won’t be
jamesn: any volunteer to explain and close this out?
spectranaut_: I will
jamesn: next issue
<scott> in aria 1.2 it was required by aria to name form roles. but in aria 1.3 that requirement was removed
jamesn: aria#2582
… typo, has a PR already
… 2 reviewers
… will get to that, no need to discuss
jamesn: aria#2580
… this has a PR
… with 2 approved reviewers
WPT Open PRs
jcraig: wpt#54126 is reviewed
… better to review this one after related ARIA PR
… please review, everyone who’s marked as a reviewer
… wpt#53966
Rahim: are these tentative tests?
jcraig: I need to refresh
jamesn: roles are not case-sensitive
… they used to be, but are not now, right?
jcraig: I think we decided a note was okay, but technically it was normative?
… need to double-check
scott: the only place that’s left talking about capitalization of roles is over in ARIA-in-HTML
… 3-ish years ago, browsers all exposed the role correctly regardless of case
… but that didn’t mean that AT worked
… so we made an authoring requirement
jcraig: was that exclusive to Windows screen readers?
scott: I don’t remember
… we did some tests, and you’re probably right that it was mainly Windows
… so we made it an author SHOULD
jcraig: why not an author MUST then?
scott: since the primary consumers of ARIA-in-HTML are the a11y checkers
… the pushback at the time was that the majority of the time it would be okay
… and it wouldn’t make sense to handle one-off cases
… like older versions of JAWS
… they said “we can’t present that as an error”
jcraig: then should there be a user agent MUST expose as lower-case?
scott: I’d support that
… then it mitigates author error
jamesn: any next steps?
jcraig: related aria#2548
giacomo-petri: about the previous point
… as a tool vendor, it’s quite challenging to deal with the SHOULD
… we have 2 options IMO: it should be a MUST or we should remove it
… we should evaluate if it’s still a problem
… it will be complex for a tester
jcraig: since it’s already an author SHOULD, you have the option to pop a warning rather than an error
jamesn: sounds very legacy, for AT that dig into the DOM
jamesn: the warning is valid, but why bother throwing it if it’s noise
giacomo-petri: all the “check manually” notes are basically warnings
… like “check if the alt text is *meaningful*”
… if we also add a “check manually” for the case of a role, it will be a lot of extra work
jcraig: it’s proven to be an issue in some combinations of technology
jamesn: that’s true for a lot of ARIA, and we don’t throw warnings in many cases
jamesn: if someone has an idea, they can agenda it and we can follow-up
jcraig; Rahim and I will talk about this offline
… possibly to clarify normative spec language
… and then we check in the PR as non-tentative
… if not, then we’ll make the normative spec change (UAs MUST expose computedrole as lowercase) and commit the PR as tentative
Deep Dive planning
jamesn: any deep dive topics?
Improving developer experience of element reference attributes
jamesn: a ton of discussion on this
… from a WHATWG issue
… where they tagged us
… mainly want to bring to everyone’s attention
… nothing urgent to do just yet
aardrian: I agree
sarah: if we don’t do anything, they might spec something new and move forward
… there are some important a11y implications in this
keithamus: I’ll help prevent that
Rahim: process question
… a11y group was tagged, so I thought I’d raise an issue
… but when other groups need input, is there a formal process for that?
jamesn: we are not officially the ones tasked with doing a11y reviews of other w3c specs
… APA are the official representatives
… and WHATWG is a special case
aardrian: I’m following the conversation there
… don’t think we need to worry about it yet
… we do want to pay attention
… but there’s not a clear problem definition, and I don’t think we should act until there is one
jamesn: thank you, agreed
Empty or non-matching values for ID reference and ID reference list - Clarification on author responsibilities
jamesn: a PR from giacomo-petri
… just needs one final review from me
giacomo-petri: there are no outstanding questions AFAIK
jamesn: okay, I think this should have been removed from the agenda
Matt: should this be covered in the APG?
Matt: present and empty is equivalent to not present?
giacomo-petri: yes
… started with tool vendors marking this differently
… spec says what user agents should do, but not authors
… so this PR clarifies that
Matt: okay, then I think we don’t need to say anything in APG
jamesn: I need to review
… and then we can merge
… no implementations needed
… no ACT
giacomo-petri: yes
… I do still have some minor follow-up work
jamesn: but nothing that needs review