W3C

– DRAFT –
ARIA WG

17 October 2024

Attendees

Present
Adam_Page, alisonmaher, BGaraventa, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, katez, keithamus, Rahim, sarah, siri, smockle, StefanS, ZakK
Regrets
-
Chair
-
Scribe
hdv

Meeting minutes

New Issue Triage

jamesn: the first item is about #2365, is Aaron on the call?

keithamus: did we discuss this last week?

jamesn: this one's 2 days old but maybe something related?

spectranaut_: is it re a math role?

Brett-Lewis: currently only way for us to get mathml out of the web page is using innerHTML

aaron: I think there's nothing controversial about this… it's about making this available more easily

jamesn: does it need something in the AAM?

aaron: yes

jamesn: who wants to do that?

jamesn: probably not for the MathML-AAM?

aaron: probably not, probably in core AAM and HTML AAM

jamesn: did we concluse role=math was pointless, I think it wouldn't do anything useful?

aaron: should we deprecate it?

aaron: I don't know how the math of this gets to the AT

jamesn: may be a separate convo from this issue

jamesn: Aaron, could you check with this issue what needs to be done?

aaron: ok

aaron: can assign to me

New PR Triage

keithamus: I have some context on this

keithamus: we're looking for input type color to allow for P3 colour spaces

keithamus: not entirely sure if this has anything to do with ARIA?

jamesn: naive question, does anyone use input type=color ?

keithamus: not really but I guess enough?\

scott: I think the question is…if HTML AAM gets more involved in this, outside of providing recommendations for accessible names for the pickers… unless changing away from using operating system picker and reimplementing everything, we could arguably provide recommendations on what the Shadow DOM of this control would be

scott: outside of that, not sure what is really necessary here

keithamus: there is a separate topic around the form styling topic, will probably happen but not for a long while

keithamus: this is a small change in terms of HTML, but still using the native pickers, as far as I understand. I just changes the colour space, which would change the picker too

keithamus: might be same kind of picker, but might look a bit different as it has different colours

jamesn: does anyone understand this enough to know what we need to do with it

sarah: it seems like there is nothing that is specified in the AAMs that would be affected

scott: if he is looking for additional stuff it is probably beyond the scope of what HTML AAM typically provides

jamesn: can one of you can write a comment back to Anne?

keithamus: probably a case of Anne saying… is there anything we need to add? And I guess our response is probably no?

Rahim: I think from what he shared internally… ultimate question was how the colours should be announced by AT?

Rahim: in which colour is the P3 colour space

keithamus: for most things it has a role description of colour picker, I think this doesnt change, it's the same colours, or maybe an alpha channel

scott: still not sure if it is the place for HTML AAM to show how native pickers work

jamesn: how they work or don't work

keithamus: most sophisticated seems to be IA 2 which has a role color chooser but nothing beyond that, nothing more specific

scott: if you start it off, keithamus, I'll chime in

Zaki, take up next please

WPT Open PRs

jamesn: re 2354, do we need reviewers?

keithamus: yes please

aaron: I can do it

sarah: you can add me too if you want

keithamus: TLDR: it's pretty much popover, copy and pasted

Deep Dive planning

jamesn: there are three issues on the deep dive planning list, would anyone propose a deep dive on any of these in the next few weeks

jamesn: tables without table headers, dashboards with tandalone cards and whitespace from accessible name/description

StefanS: the cards one sounds interesting to us

jamesn: do you want to facilitate one?

StefanS: we have a lot of cards… 

jamesn: we need a way/proposal forward in the spec too, then try and get agreement on that

sarah: I have some things to write up about interactive lists after TPAC… it's related but not ready for deep dive

jamesn: once it's ready can you add it?

Draft Charter for ARIA Working Group

<dmontalvo> -> Proposed ARIA Charter

<dmontalvo> AC Questionnaire for ARIA re-Charter

jamesn: can people please take a look over it?

dmontalvo: we're a step forward now, the charter was discussed in June, then it went through horizontal review and it's now available for AC review

dmontalvo: I would propose for everyone to talk to your AC reps so that they can support us

dmontalvo: the change is really just wording like we discussed in June, nothing significant has changed

dmontalvo: if AC reps could review this they can support it

jamesn: I didn't see the questionnaire yet

dmontalvo: its open as of this morning, I've just shared it in the minutes too

jamesn: thank you Daniel

jcraig: in the ARIA section in the deliverables, I was surprised to see first public of ARIA, does that refer to the living recommendation?

dmontalvo: yes this is why it's listed there

jcraig: we'll take the versions of, when it becomes an approved evergreen, right?

dmontalvo: we probably won't see all specs go everygreen… but some will as it fits many of the specs, but we'll also submit specs for recommendation as well

mario: some of the sames of the living recommendations have a number in their name, I'm not sure why, feels like there shouldn't be one?

mario: for example 1.2 living recommendation?

mario: I think that's an error

jcraig: not in the charter though

jamesn: I agree we should probably remove the version numberes eventually, hesitate to do that now as some of the specs in there are in the process already

<scott> some of these having been living standards with version numbers for quite some time

dmontalvo: folks could also approve the charter but then make suggestions

jamesn: can the name change once it is a living standards? probably… I would say not worry about it now… because people might go back and think the one with the number must be the latest one

jamesn: if we have ARIA without version number and also 1.3 that would be confusing

dmontalvo: would also be an issue for the spec's shortname in the TR docs

jcraig: one more procedural question… in the graphics module and the graphics a11y mappings… they are the only ones that are not living, is there a reason or should they be?

jamesn: I expect it is unlikely for many changes to happen to them once they are ready

jcraig: it's possible they may get changes due to the testability stuff

jamesn: I think it's fine… they're recommendations now though?

jcraig: ok can leave them, don't need to change the charter

jamesn: we probably didn't think about them too much as they are IMO least important of the work in this charter

jcraig: would agree

Feature: Braille only regions for student testing

aaron: I invited Brett Lewis from JAWS to the meeting today… we realise we don't expose everything through Chrome in Windows… it comes at a cost because of the architecture, so we'd like to get rid of it and only expose as @@@

aaron: to get rid of the iSimpleDOMNode we need to find a way to support that AT vendors opened as real use cases in their software

aaron: it's so that students can show they can the words, if the TTS would read it to students it would basically be cheating

aaron: so they'd put it in a large region for it to 'this should only be read in braille'

Brett-Lewis: some of the idea is… reading in braille is analagous to reading

Brett-Lewis: they needed the ability to only make it available in braille

Brett-Lewis: we've had this around for the last 8-9 years

aaron: I don't like adding new things to the ARIA spec, but would like JAWS and others to be fully standards compliant, and not add it as a backdoor

aaron: because it sounds so specific, probably not much reason to abuse it

jcraig: was trying to think of ways to make it work with existing reasons

jcraig: there isn't a good way to translate from the braille in Unicode probably

jcraig: we wouldn't want that speech get in the way of them reading, but it does mask the value of what that braille is representing

jcraig: so… is there some variant of this… we have braille label and braille role description

jcraig: you're trying to render it on screen, because you want a sighted braille user to read it

Brett-Lewis: just that you have a text doc on screen and the braille reader to only access it as braille

Brett-Lewis: otherwise screenreader user would not be able to support different modes of braille

Brett-Lewis: eg grade 1 or grade 2 braille

jcraig: so you want the user's braille prefs to still work, but no speech

jamesn: why wouldn't label work for that?

aaron: this may have bold face or rich text… we're saying this whole region is braille

jcraig: almost like you need a braile contents kind of thing

Brett-Lewis: the real advantage of braille only reason is that you could see exactly what the braille user would get with their ability to have braille prefs respected

jcraig: a lot of braille readers aren't completely blind, doesn't this still allow the cheating?

Brett-Lewis: it's not about testing fluency in braille… it's testing the ability of reading, distinct from hearing audio, whether that's braille or text

aaron: it matters enough that four testing orgs agreed they needed it

jamesn: from my understanding if we want to add this new feature, we would need at least two AT say they need to support it

Brett-Lewis: I know JAWS would, not sure about NVDA

jamesn: ok so we need one other than JAWS and then commitment from at least two browsers that they want to support this

jcraig: should the issue say ETS instead of ATS?

Brett-Lewis: yes

jamesn: can we get any of the testing companies to put in a use case to make sure we're solving what they really want rather than what they think they need?

jcraig: doesn't have to be super long but a gist or wiki page that lists out the use cases and why the existing technologies don't solve the need

Evaluate whether use case needs a new ARIA feature — a way to define page-wide keyboard shortcuts agendabot]

jamesn: there's already been a bunch of discussion on that

StefanS: it's basically a discussion in disguise re what's the best way to do shortcuts for all users?

StefanS: there are best practices for that, like F1

StefanS: what's missing a bit… to clarify what is the best technique to make this work for all users, not just screenreader users?

aaron: also worth deciding whether we want to do something at all

aaron: might be good to have Brett describe how this is done in JAWS

Brett-Lewis: what we worked out… Facebook doesn't use it anymore, but Twitter does… 

aaron: it's still on Facebook

Brett-Lewis: there's essentially this JSON object… the reason we as a screenreader wanted it, is because sites have these single letter shortcuts, that the screenreader uses for quick navigation on a web page quite often

Brett-Lewis: eg J and K let you move to next and previous tweet

Brett-Lewis: if in JAWS you don't let them pass through to the web page they are used for the application itself

Brett-Lewis: what we do when we see the page loads, we see this object is available and know that the web page wants to use these keys and let them pass through instead of the JAWS shortcuts

Brett-Lewis: it's not the same kind of use case as F1… we need a way to have the short cut keys that are in use of the page, as some kind of structure, like right now it is a JSON object

Brett-Lewis: this also provides a nice way for us to give an overview of what the available shortcuts are

Brett-Lewis: could be done in another way too, completely agree

jamesn: wanted to ask Brett… is there a way for the user to override that override?

Brett-Lewis: there is, don't remember the exact keystroke

jamesn: would the user be aware of the exact keystroke?

Brett-Lewis: if it's discoverable, that's a harder question,we try

<Zakim> jcraig, you wanted to suggest this should be a general web feature (OpenUI?) and mention this is more common a Windows SR problem.

Brett-Lewis: there's a setting in JAWS that says I don't want to honour that website's reserved keystrokes

Brett-Lewis: eg I only want my own

jcraig: by default, VoiceOver doesn't intercept keystrokes

jcraig: this is coming from the need of the Windows specific screenreader

jcraig: but this feels like a feature that could benefit from broader adoption

jcraig: to have a registry of keyboard shortcuts that are used in the web page solved a lot of different problems, incl i18n

jcraig: it's also in a lot of the Google Suite… it only works because Google localises the shortcuts

jcraig: eg on the French keyboard you have to hit Shift to type a number

jcraig: there's a lot of benefit beyond what we would shoehorn into ARIA

jcraig: maybe the existing shortcut feature could give us enough

StefanS: I second you jcraig, but I want to have the format in a way that all users could benefit

StefanS: JSON could work but would need to be a standardised JSON object so that other tools can hook into it

aaron: I asked NVAccess aboutit and they said they'd announce the shortcut, but they don't do the passing through

aaron: I know Matt King didn't really like the way that works

aaron: isn't the easiest way to do this is an aria description

aaron: if only JAWS is going to consume the object property it's not worth it

aaron: I do hear there's potential for some kind of feature

<Rahim> Was this the problem accesskey was trying to solve?

<Zakim> jamesn, you wanted to say that not everyone in a locale uses their local keyboard ;)

keithamus: was discussing this kind of feature with Anne… I do think it should be embedded in HTML, a lot of things to get right though… might want to pop to the WHATWG if we want this

jamesn: not everyone in a locale uses their local keyboard

jamesn: I do agree it can solve problems beyond screenreaders, eg if voice recognition that certain keys work in the web app they can make sure not to interfere with it

scott: definitely seems like if this were to be an ARIA feature I would want it specifically carved out what this feature does for AT

scott: if it's just 'here's all the keyboard commands' that seems like a wider use case… what's the specific benefit for AT of that information

scott: eg special behaviour that certain keys have

keithamus: I strongly think this should be a feature that should exist in HTML, it goes beyond HTML

keithamus: and the fallout of that being in HTML should probably something that does something in ARIA

<Zakim> jcraig, you wanted to mention SC and AK

jcraig: an example of how this could be used in another AT … not just what the commands are but also what they are tied to is a useful feature… eg we could have a button for posting mail or whatever you want to call it

jcraig: HTML has some functionality that Opera used to support, a meta rel , that would render a toolbar

jcraig: can definitely see this useful outside the screenreader use case

jamesn: could feed into the work that Lisa was doing?

jcraig: could also tie into aria actions

jamesn: who is going to take this to Open UI?

keithamus: I'll do that

Rahim: would the accesskey be a way to do this?

keithamus: problem with accesskey is that modifiers are not just OS independent but also web browser independent

keithamus: there's no way sites can reason about that, and also no way to allow that, would be a finger printing issue

keithamus: OSes don't want to yield the modifier info to the browser… and even if that they did it is really hard to figure out the OS

jcraig: we once looked at are there any keys that are available that aren't used by some application somewhere? answer was no… some are even used by specific locale's keyboards

jcraig: it's a big localisation and locale mess

keithamus: there's also a semiotic vs ergonomic … we use WASD in computer games because it's conveniently located… but for productivity apps the keys are often semiotic, eg p for print

Brett-Lewis: just wanted to say… I think this is becoming a much more important consideration… have seen so many applications that assign single letter shortcut keys, eg YouTube, Gmail… goes on and on… becomes a more cumbersome experience for a screenreader to use… I don't have a preference for how it gets handled, but the longer we wait the longer we need the workarounds we've used for the last 8 years

Brett-Lewis: in other words, it's an important feature, I hope we can move it forward

jamesn: I think the first step is to take it to Open UI and see where the progress goes from there

Brett-Lewis: makes sense

jcraig: most of the shortcuts aren't discoverable for sighted users either… took me years to find out c is for compose in Gmail

jcraig: can take years for standards to make, or undo previous mistakes

jamesn: I think we all agree this is important… don't think ARIA necessarily going to have all of this functionality, probably a subset of it

jamesn: thanks everyone!

Minutes manually created (not a transcript), formatted by scribe.perl version 237 (Fri Oct 4 02:31:45 2024 UTC).

Diagnostics

Succeeded: s/spacs/spaces

Succeeded: s/spce/space

Succeeded: s/evergreen/evergreen, right?

Succeeded: s/jamescraig/jcraig

Succeeded: s/thsi/this

Succeeded: s/thsi/this

Succeeded: s/it/the issue

Succeeded: s/ETS/ETS instead of ATS

Succeeded: s/indepedent/independent

Maybe present: aaron, Brett-Lewis, dmontalvo, jamesn, jcraig, mario, scott, spectranaut_

All speakers: aaron, Brett-Lewis, dmontalvo, jamesn, jcraig, keithamus, mario, Rahim, sarah, scott, spectranaut_, StefanS

Active on IRC: aaronlev, Adam_Page, alisonmaher, BGaraventa, Brett-Lewis, dmontalvo, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, jamesn, jcraig, katez, keithamus, Rahim, sarah, scott, siri, smockle, spectranaut_, StefanS, ZakK