Meeting minutes
<jamesn> meeting ARAI WG
New Issue Triage
jamesn: 8 new issues
… #1939
… this is a good idea
… none is preferred
spectranaut_: is this a good first issue?
spectranaut_: maybe reach out to andreacardona
jamesn: #1937
… added it to the live regions update project
scotto: yeah, this has essentially already been filed
scotto: duplicate needs to be closed in core-aam
jamesn: I agree
… closed it
… #174
spectranaut_: just a follow-up issue for me, no milestoning needed
spectranaut_: jcraig, you’ll resolve this with #176
spectranaut_: ditto for #175
jamesn: #1936
… we refer to things begin focusable but don’t define what that means
… and there are often questions
spectranaut_: I’m not familiar with how someone could misunderstand it?
jcraig: one example is `tabindex="-1"` — focusable in some contexts, but not by tab key
jamesn: svg *does* define focusable. html kind of does, but it’s not exported
… we need to think about how we use “focusable” in ARIA and whether it needs clarification
… let’s agenda it for next week
… #486
… this is html-aam
scotto: impetus for this is that anne noticed that it was not spec’d in html-aam
… which is because it was made obsolete back in HTML4
… we can go in and just say they’re all generic
jamesn: or we could say to treat it the same as HTML
jcraig: xmp is a little different, but agreed on the others
jamesn: how is it different?
jcraig: different from the context of user agents. One example is you don’t need to escape your < characters.
jamesn: okay, but for accessibility, that doesn’t matter. we could just say it maps to pre
… maybe we should actually un-obsolete xmp ;-)
… so I’d prefer not to see explicit mappings for this but to leverage existing relationships
scotto: largely, they’re going to map to generic
… and even in the cases where they don’t, like `strike`, we can say it maps to `del`, but for what benefit? No one’s going to go back and implement that
jamesn: #1934
… editorial
New PR Triage
jamesn: #176
… jcraig, do we need reviewers?
jcraig: yes, I’d like scotto to review
scotto: I’ll get to that
jamesn: #485
… this sounds editorial
… dmontalvo, could you review this?
dmontalvo: yes
jamesn: and I’ll also review
jamesn: #484
… still draft
… already have 3 reviewers
… but help yourself if you’d like to review
add proposed header and footer roles
jamesn: #1931 PR
… waiting on my and spectranaut_’s review
… scotto, anything to say on this?
scotto: I brought this topic up a couple weeks ago
… adding these roles to allow for header and footer as exposed as something beyond generic in cases where they’re not exposed as landmarks
… because of the work going on with minimum role and contextual roles
… if these were given attributes related to naming, etc., we could fall back to group, or we could try to match semantics of what HTML intends
… we reached out to HTML editors and they essentially said “fine”
… so this PR is the result
… the open question is “do we want these roles? would anyone actually benefit?” or would they just be better fallbacks?
jamesn: would we expect AT to do anything different? and if so, what?
scotto: my rationale had been that they’d be mapped to the group role but have different role descriptions, like “section header” and “section footer” to differentiate them from full page headers and footers
… if they weren’t named or given tabindex, etc., then they arguably should be able to be treated as they are now
… like JAWS and NVDA will essentially ignore these groups if they’re not given names
jcraig: same with VO; it’ll just skip over
… so this is a fairly minimal change, but I agree with scotto that this would be an easy way to make sure no purposeful semantics are lost
jamesn: but if nothing is going to expose them, then what’s the point?
jcraig: because it would be more meaningful *if* were to expose them
jamesn: but how could it actually be useful to a user?
scotto: the basic goal is to just provide something more useful/logical than group
jcraig: for example, a header with a heading in it would currently be presented as “foo, group. bar, heading” but it could be “foo, header. bar, heading”.
… it’s super easy, low impact to users. They’re hearing something anyway, and this is just slightly more specific
… but the question could be did the author *mean* to use header when they actually intended something more generic like div. Could it be misused?
jamesn: okay, fair enough
… if anyone else wants to review, please go ahead
Update from PR #1018 for nameFrom: heading
jamesn: this is waiting on my review
… I merged the ARIA common stuff
… so this should be ready to look at now
… jcraig, do we need to wait for bgaraventa?
jcraig: no, I don’t think so
jamesn: oh, we need to wait for the accname changes, tests, etc. before we can merge according to our new process
spectranaut_: you can +1 it, it just can’t be merged
jamesn: okay, I’ll review it
… this one definitely needs implementations, right?
jcraig: at least tests, and no objections
jamesn: right, it needs commitment to implement
spectranaut_: yes
jamesn: we can put something like this in accname since it will soon be a living standard
Follow up from ARIA and AT discussion from F2F
jamesn: we didn’t really conclude this discussion at the face-to-face
… don’t know what do with this one, spectranaut_, any ideas?
spectranaut_: MattKing and aaronlev should be present for this discussion
jcraig: I can give an update
<jcraig> Bocoup proposal w3c.github.io/at-driver
jcraig: Lola and Mike Hennessy asked about a proposal called “AT driver”
… my feedback was that this is a huge security backdoor
<jcraig> https://
jcraig: but did point them to a few other projects: WPT, the new AOM issue for computed accessible node, web driver BiDi
… I think this one has potential and almost certainly has other security professionals working on it
… security should be a top-level goal
jamesn: okay, so that’s one part of the general ARIA+AT topic
… does anyone have anything to add on this? how we can more effectively work with AT, to communicate what we want from them?
spectranaut_: one thing we talked about in the face-to-face is that there is some desire for advice on how screen readers should handle certain roles
… so there could be cases where we want to add non-normative advice to the spec, under each role when appropriate
jamesn: that sounds good, maybe in the editor’s core we should decide how to do that in a way that’s easily consumable for AT devs
spectranaut_: and this will increase communication because we can document it and hand it over
jcraig: yeah, non-normative notes seem fine
… I agree about editors review, maybe put it in a style guide
… e.g., don’t give prescriptive guidance, but offer examples
… keep it from being modality-specific, platform-specific, etc.
jamesn: yes, would like to see some new CSS to make these more conspicuous, differentiate them from advice for other audiences
spectranaut_: do we have any existing candidates?
jamesn: yes, the annotation stuff
jamesn: cool, I think that might be a wrap?
… anything else?