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!