Meeting minutes
What do. you want to work on this year for ARIA
spectranaut_: continue to work on testing for Core AAM and HTML AAM
continuing to improve the contribution process
Andrea:
<jcraig> s/Andrea: /Andrea: would love to help with contributing process/
Adam_Page: open PRs, aria-actions, WPT
sarah_higley: taking Adam_Page's freetime
sarah_higley: aria-actions, interactive lists, etc
<spectranaut_> sarah's interactive lists: w3c/
Matt_King: aria features: aria-actions, live regions and notifications, and finally dialog, in particular particularly non-modal or modeless dialogs
Matt_King: working on process to get both practices and WPT tests landed simultaneously with the spec change...
<spectranaut_> Matt_King also mentioned ARIA-AT tests
dmontalvo: 1.2 Rec process, ARIA-AT showing results now
cyns: interactive elements in general, in particular, AOM incubations, Open UI, overlap with ARIA, etc
cyns: Chrome implemementations, finding gaps between implementations, bringing more Googlers into the process of contributing
DG: Live Regions is the primary driver for my participation, joined because it's been overloaded for cases it wasn't designed for. Understanding users
DG: constantly hearing things like "the web doesn't do that".... Most web apps have very poor accessibility
DG: Would love to get the richness of desktop accessibility to the web
BenBeaudry: Live Regions, pushing in Edge and Chromium. New to this group, but not to Accessibility (in Chrome, etc)
BenBeaudry: want to push my boundaries to contribute to the design process...
BenBeaudry: all platforms... Mobile, Linux, etc. the web is the equalizer
BenBeaudry: need to rebuild expertise lost from people that have left recentlyt
jcraig: focused on testing. all the other wg builds these tests to make sure that it works in at least 2 implementations so that whenever there's a change to the specs we see the differences and where it breaks. we're just scratching the surface
jcraig: just the tip of the iceberg
jcraig: a related area I'm interested about is find a path forward for enabling all these tests and allow for relationships between nodes
jcraig: more to discuss in the meeting tomorrow
jamesn: excited about live regions.... likely a replacement
improvements to tables and grids... even HTML tables... would love to be able to do everything we need to for complex web apps
accessible dataviz
scotto: aria-actions and interactive lists.... composite widgets. fixing the implementation and UI paths
getting clarity around modeless/non-modal dialogs.... Notification API, etc
Agree with jamesn that a notification API can coexist with Live Regions
Open UI scope: are there new ways to think about old patterns like list boxes... Are there better patterns we could promote instead?
Siri: interested in polishing patterns/widgets like tables/grids
not well supported in all screen readers
determining commonly used widgets and patterns, to tackle the interaction problems
Rashmi: mostly how ARIA interacts with screen readers. Correcting the edge case problems.
spectranaut_: summarizing
focusing on the list that aren't slotted for discussion in this F2F
ARIA-AT tests
validation tests
exposure of more surface than currently testable
how to bring the richness of native to the web
polish of old patterns, and anti-patterns... Open UI is working on this to some degree
specific examples: interactive lists, tables and grids, dataviz, etc.
normalizing platform differences
how to facilitate and mentor the next generation and make sure knowledge isn't lost
<spectranaut_> documentation: https://
and https://
<Zakim> cyns, you wanted to ask if we can put links to the various tests suites into the minutes?
cyns: old Edge tests not yet landed in WPT
jamesn: in terms of getting mentorship and new blood, I'm talking to A11yCamp Bay on Friday
open to suggestions for exciting topics to share
DG: re: live regions, devs will *think* they have written Live Regions well... How do they know? Are these in those tests?
Matt_King: ARIA-AT has manual tests for all manner of Live Region tests
Much is left up to implementations...
APG only has 3 or 4 Live Region tests?
Scott and Sarah also have live regions tests
DG: devs may be hesitant to throw excess notifications if they could see the excess of text thrown at the user
Matt_King: back-burner project... simplified accessibility tree and events would be a good visualization
<cyns> Old Edge WPT UIA Implementation tests for HTML MicrosoftEdge/
<cyns> IIRC there were ARIA tests at one point, but they may be lost the sands
Matt_King: including live region "flashes"
jamesn: start with a UI for the tree
<cyns> Demo of Chrome Dev Tools A11y Tree viewer https://
jcraig: re: DG's comment that web devs don't test live regions, imagine how foolish a web dev would be for writing CSS but never reloading the page to view it. That's how many web devs test accessibility. the flip side though is that you can't overload a new web dev with too much SR verbosity, or it will backfire and they'll react with fear rather than empathy.
jamesn: standards and wcag can be to blame for testers thinking verbosity needs to be high
re: live regions: don't overcomplicate the notification API with a requirement for Live region completeness
cyns: screen reader visualizer experience, could recruit others to build it
sarah_higley: visualizer could show when speech jobs get trampled with live regions
and other interaction problems
… edge cases re: live region queueing
spectranaut_: will make a visualizer dev tools issue in the tracker
spectranaut_: jamesn what about fixing tables
jamesn: wanted for a long time, particularly large tables offloaded to the servers, sectioning scrolls out of view, editable cells, virtualization…
<scotto> big +1 to how to exposed 'virtualized' content in a better way
trying to keep focus in the right part of the table while the virtualized tables are being re-rendered
sarah_higley: virtualization of tables should consider lists and other container types
Aaron: including more things in HTML, like keyboard interaction by default rather than accessibility-specific interfaces, so devs don't have to specialize
<Matt_King> Virtualization proposal https://
BenBeaudry: Matt_King was talking about ARIA virtual content.... I implemented support in Chromium. needed SR support
DG: concerns re: performance
Matt_King: read through this before the meeting time tomorrow
cyns: accessibleObject (abandoned API ) behind a flag in Chrome
jcraig: echo what doug mentioned, we talk about virtual content, performance was a concern. the other concern -- the reason we couldn't implement -- it violated the new html design principles -- strict guidance to never let the web know you are using assistive technology. actually that is impossible to prevent, too many heuristic ways to know this. this has made it difficult to explore many new ideas.
<jcraig> scotto: consider attribute parity with HTML
<jcraig> HTML has a partial solution to virtualization with the lazy attributes.... What if we leveraged existing or created new HTML features
<jcraig> Matt_King: many problems we are discussing are so magnificent in size, if we can focus all our efforts on them one at a time, we could solve them in sequence
<jcraig> jamesn: BREAK until 10:30 AM Pacific (14m)
Introduction/Overview of Automated Testing
<jamesn> w3c/
jcraig: I work on a11y standards at Apple in San Jose, I used this to explain to my team what I'd been working on for a couple months
jcraig: I updated it to share more details on the history of WPT and where I'd like this to go, and at the end it trails into demos
jcraig: ask questions, feel free to interrupt
jcraig: cross-browser a11y automation is what I'll call this effort. I wanted to explain what we're talking about, because automation and accessibility automation means different things to different people
jcraig: tech stack: we have the web author and end user. The web author is most of you, and most of us are end users as well. Some of us are end users with ATs too
jcraig: the web author writes some framework that gets to the web platform as HTML CSS and JS. This is interpreted by the rendering engine. For apple this is Safari, for others this is Chromium
jcraig: Inside that browser stack is the implementation, we refer to this as WebCore. This handles events like mouse clicks and key presses, output like rendering pixels
jcraig: it handles a bunch of background API like XHR requests, etc.
jcraig: when you get into a11y, the stack is a bit different. Inside the rendering engine is another portion of it that runs on demand, and some of it overlaps. In webkit, this is WebCore/Accessibility. In Chromium it used to be similar
jcraig: this takes all of what the browser has rendered on the screen, and turns it into its own internal model of an a11y tree with events and things, and exposes it to the platform. In Mac this is AX API, on Windows this is IA2, UIA, etc.
jcraig: switch controls, screen readers, ATs interface with that and present it to the user.
Matt_King: on these slides do you have graphical representations?
jcraig: yes, want more detail?
Matt_King: no, I've had to explain the same stuff to other non-accessibility people, wondering if the slides are shareable
jcraig: I can share a PDF version of this
jcraig: let me double check
Matt_King: I imagine there's other people who also need to explain this
(general agreement)
jcraig: there are a lot of pieces to this stack on screen. Feels like 20 years ago no one was doing automated testing with the web platform, but more and more pieces have been possible with automation
jcraig: I"ll explain the web automation stack next
jcraig: started with platform-specific automation. This is why UIA is named UI Automation. Apple has its own automation framework
jcraig: now a native app dev would use something like XCUI tests for XCode tests, these leverage the platform a11y api
jcraig: there are general component versions of this. Right now a third party dev can't automate someone else's app, so you can't automate VoiceOver except for the APpleScript bridge, but we have our own solution for automating our own products
jcraig: likewise, most people probably thought of these client automation tools like axe-core.
spectranaut_: we call these the validator tests
jcraig: does your DOM structure comply with WCAG, these sort of things
jcraig: WebDriver, Selenium started off as this sort of thing as well before they moved into the browser
jcraig: for Windows there's another little arrow I'm missing that comes from this AT over here into the WebCore implementation
jcraig: it doesn't work that way on mac, but it does on Windows
Matt_King: JAWS is using IA2 and UIA and MSAA, they're not processing the DOM
jcraig: let's not divert into that
jcraig: those are the two platform-specific, client automation
jcraig: there's also engine internal automation. In webkit, most are in this section called Layout Tests, There are 82000 tests, in Chromium there are probably (missed number)
jcraig: all these engines are duplicating the work. Webkit, Chromium, Gecko, all have these thousands of tests
jcraig: sounds like a lot, until you realize how web platform tests has 1.8mil tests
jcraig: Up until now the only a11y things they were doing crash tests. Val added these IDL tests for ARIA
jcraig: someone wrote those in the past year or two. Not testing the accessibility internals, only testing that this works
jcraig: look up Acid3 tests, with a weird css smiley face
jcraig: that wasn't specific to a11y. But all the automation tests are in these LayoutTests
jcraig: the cross-browser automation project is a collab between w3c and a whole lot of other entitites
jcraig: 1.8 million tests, with a whole bunch of features. Shadow DOM, css, etc. Not a lot about a11y
jcraig: been around for about 10 years, only 3 years ago they started this project called Interop
<jcraig> “WPT Interop 2023 is a cross-browser effort to improve the interoperability of the web — to reach a state where each [Web API] works exactly the same in every browser.”
<jcraig> https://
Matt_King: what does works exactly the same mean?
jcraig: heh
jcraig: I'll come back to that in a demo
jcraig: this (graph) was as of this week or last week. Webkit and Edge keep leapfrogging eachother
jcraig: there are lines for each of the different implementations up until May, now
jcraig: Chrome, firefox, safari, and interop
jcraig: axes are months in 2023, Y is percentage towards 100
jcraig: this is a selection of features that devs agreed on we would work towards interop this year
jcraig: the interop line is lower than the browsers, at 73% passing interop
jcraig: the features include inert, flexbox, etc. 73% of those are passing in all implementations
jcraig: the browsers are in the high 90s, interop in high 80s at end of last year
jcraig: we all compete to be the best and work together along the way
jcraig: someone said let's get a standardized a11y tree, and everyone said that's not gonna happen but love the enthusiasm
jcraig: so working together to get more a11y testing
jcraig: went to browser testing and tools group to say we need more api, and browser testing & tools said make it a DOM extension. I said no, we got computed role and (??) out of that
jcraig: based on that, I started shopping it around, Alice was at google and said it'll be really tedious to write webdriver tests for everything in WPT and others had the same concerns. So I wrote a testdriver wrapper around webdriver that simplifies the test writing
jcraig: it still uses webdriver behind the scenes, but makes it a lot easier to write tests
jcraig: literally one line of js
jcraig: I've tried to write tests to make sure they all work, I haven't written comprehensive tests because I want all of you to write them with me. But there are now a few hundred more tests in WPT in the last couple months
jcraig: (listing browser passing numbers)
jcraig: all hitting around 90% of these tests
jcraig: firefox is way down below, but that's because they're working on adding support for these new webdriver props. Jamie Teh is making great progress
<jcraig> Cite: https://
jcraig: this is a subview in these tests inside the WAI ARIA tests
jcraig: all of them are passing basic.html, getting some differences in roles.html, safari has 2 bugs, chrome and edge have some bugs with synonym roles
jcraig: filed these in browser trackers and re-associated them with this triage view in the WPT dashboard. It's a cool view, you can see all a11y tests and see where browser diffs lie
jcraig: benefits are that literally thousands of a11y tests are now unblocked. Specifically computedRole and ComputedLabel, but there are thousands with those
jcraig: bugs have been discovered and resolved in webkit, chromium, and gecko. Also found spec ambiguities
jcraig: one of the reasons I'm so excited about this is there are new incentives for writing these tests I didn't see before. Browser engineers always had incentives to write these tests, but before it was easier to write interal tests than WPT tests
jcraig: but spec authors and w3c contribs had incentives to write it
jcraig: now the change is web devs who find this weird a11y edge case bug and need to file issues in browsers, and it's really complicated to find a process to write tests. So there's a lot of incentive to write one tests and get it running, submit to WPT, spawn all these bugs, and once it's fixed they shouldn't regress
jcraig: so it's a lot of incentive for the web devs to take over this
jcraig: next steps are that there are more tests currently in review, hundreds more coming. Nolan has a manual test last year that's updated to an automated test this year for shadow dom slots
jcraig: I'm in the moment recruiting other stakeholders to write more tests. Want to extend beyond role and label, Scott mentioned role and attr parity, that could be through ARIA or this other AOM issue
<jcraig> WICG/
jcraig: the AOM issue is computed accessible node
jcraig: potentially this could be an accessibility focus area for 2024. This work doesn't contribute to that final score yet, can't test implementations against eachother since there are known diffs
jcraig: let's go into demos
jcraig: WPT github dashboard
jcraig: URL is wpt.fyi, these are all the 1.8 mil tests. You'd be tempted to go into accessibility, but most of them are not
jcraig: it's considered an antipattern to put things in there. If tehre's a spec, it should be in a top-level spec directory. There's a top-level accname and html-aam directory. At the bottom there's a wai-aria directory
jcraig: there will be more in here for svg-aria and svg-aam, but those are draft PRs now
Matt_King: what are those in the a11y folder, e.g. crash tests
jcraig: those are specific crashes that occured during implementation
spectranaut_: Aaron wrote them!
jcraig: thanks for writing these, I went in and filed a webkit bug because there were more crashes in firefox and safari. There isn't a spec associated with crashing, so those are in the accessibility dir
jcraig: I have this search query to get all teh current a11y tests, I pasted in earlier
jcraig: this is not a permanent link because I don't know how to get regex working in the query. This is just the paths I knew about at the time. Includes crash tests, accname, html-aam
jcraig: and the new aria tests too
jcraig: if you dig into accname or aria you see a manual dir. I put them there because they're not being maintained
spectranaut_: they are being maintained by me
jcraig: you run them?
spectranaut_: yeah, we have hacked-together tools to run them. It's a long story for another day
jcraig: OK, valerie is running the one implementation
spectranaut_: only html-aam and core-aam
jcraig: that's the thing that runs the client server and etc etc?
spectranaut_: no actually, I have to look at the manual tests in ARIA, nvm. I was thinking about html-aam and core-aam
jcraig: the stack to set it up is really complicated
spectranaut_: the html-aam and core-aam are maintained
jcraig: anyway they're manual and not run by the dashboard implementation
jcraig: so some of them could be converted, and when converted I'd expect them to be deleted in the manual, and created as a new test outside of the manual tests. Currently not adding to any of the numbers
jcraig: in ARIA, good news. Besides the firefox stuff jamie is working on , we have high levels of pass rates across all implementations. Couple bugs I mentioned, we can go into those
jcraig: if you click on roles.html you can see specific results for each, you can see passing for alert, alertdialog, etc. All missing results in FF, one failure in Safari -- no two. Wanted you to see there's a switch abve the table called show details
jcraig: increased cursor size makes it easier to see
jcraig: showing us all his computer display settings
jcraig: cursor doesn't show up on the shared screen! New bug to file
jcraig: in details, see associated bugs
jcraig: anyone who are listed as reviewers have access to triage mode, and you can click on any failing cell and click triage and add bug. Be careful adding the bug because you can't take it out afterwards
jcraig: don't do it unless you're sure that's the right bug
jcraig: in html-aam tests --
jcraig: we have yellow and red in html-aam, there's quite a bit more here with associated bugs. So table roles, you can see there are one, the bug for rowgroup
jcraig: so this is how the dashboard works in WPT
jcraig: next is interop a11y investigation. This is a github project, check the issues list. Issue 3 is the scoring criteria
jcraig: we meet once a month, and decided how to measure the success rate, decide what to tests, how to test it. Have it running in chrome and webkit. Gecko isn't done yet
jcraig: remaining portions are all based on writing these tests and getting them running. A handful are completed
jcraig: all these other tests in accname and role are things you all can take
jcraig: tried to separate them out so it's easy for someone to take them on as an issue and PR
jcraig: some of the other things include things like computed parent and children, that's an AOM issue
jcraig: note to anyone here for anyone who works for a big org. Some grey areas with WPT and IPR. Whoever owns github/web-platform-tests isn't assocated with that, so there isn't an IPR policy
jcraig: so if there's an API discussion that should happen in a w3c group, or html. Just tests are OK, but discussion should not happen in this repo because it's ambiguous what that would mean for your company's IPR
jcraig: (listing issues in accname)
jcraig: there are running tests for these, but they're usually just a single test
jcraig: interop 2023 dashboard
jcraig: I mentioned the diff between focus areas and implementation areas.
jcraig: inert is at 100%, wooooooooo
jcraig: as of the most recent Safari tech preview, we're at 100% inert tests
jamesn: does that mean we're not testing enough?
jcraig: probably
jcraig: in stable inert is still down at 94%, because of safari. But at experimental has 100%
jcraig: in a11y testing you can see the investigation is at 60% and that's based on that earlier criteria
jcraig: chrome jumped ahead, (reading %'s of each browser in dashboard)
jcraig: I'm going to run some tests now
jcraig: and then show some tests, because I think that's powerful as well
jcraig: (running accname tests in fully white terminal with black text on screen)
(now jcraig has a black terminal with green text)
spectranaut_: old hacker imagery
jcraig: back on topic
jcraig: so there's going to be a bunch of spew on screen, most of it is normal
jcraig: it's popping up browser windows, running tests in the accname dir, it's completed now
jcraig: the important part here is this bock of text saying ran X checks, subtests, tests. Expected results 31, unexpected results 1
jcraig: that matches the dashboard, so that's accurate
jcraig: the last line of text is the run script has some args. accname is the path, and before that is safari. Can replace safari with chrome, and now it runs for chrome
jcraig: this is running locally on my machine, on my copy of chrome and my copy of safari tech preview
Matt_King: so you can only test things on your machine? not the windows version?
jcraig: this should be the same because it's testing browser internals
jcraig: I'm just going to run one of these, the one that failed
jcraig: which test failed is in the logout
jcraig: running that with the test path
jcraig: the difference will be that it pauses that test in the window with it open
jcraig: running one a time pauses with the window open
jcraig: you get a popup when you try to interact with a window controlled by automation
(jcraig being evil and making people guess what to click in the popup)
jcraig: you all should read the documentation tonight
jcraig: click stop session in the dialog
jcraig: (reading message in the test details)
jcraig: also going to show you -- that was running locally -- when you instantiate a PR you can see the results online in a different interface
jcraig: this is one of the issues where I noticed there were ambiguities in the way SVG defined these roles, differences between chrome and webkit
jcraig: in order to inform that discussion I wrote a PR with a new test. (showing the PR diff)
jcraig: I put in what webkit is returning in data-expectedrole. The script is AriaUtils.verifyRoleBySelector
jcraig: it compares the computed role (not the role) against what I defined as the expected role
jcraig: to see the results, go to conversation review, in the checks usually the last three are the experimental results for chrome, ff, and safari.
jcraig: I click on the results from safari, and you can see 3/3 passed, there's a visual comparison of the results
jcraig: before the tests there were no results, after the tests all three pass
jcraig: going back to chrome's view, 0/3 passed in the visual comparison
jcraig: if you click show details you get the entire fail message, including markup and expectation vs. result
jcraig: so this is an area where the spec is ambiguous
jcraig: so my call to action: if you are interested in writing or running tests tomorrow, please read the documentation tonight and get it running tonight
jcraig: I can help if you have a mac. If you have a windows machine or chromebook or linux I'm not the one to ask
jcraig: try to get your machine configured tonight, I"ll paste in docs links
<jcraig> https://
jcraig: this is what worked for me on my mac, the second link has more info for other systems
jcraig: (going through the info in the doc)
jcraig: there's a lot of documentation not in the wiki, but in the source itself.
jcraig: in accessibility, in addition to crash tests there's a readme
jcraig: it says not to use this directory
jcraig: in accname, I added a name dir for the name computation. At some point we'll have computed description and can add a dir for that
jcraig: lots of files for comp_tooltip, etc
jcraig: embedded control was failing, let's look
jcraig: in the file there are a lot of TODOs, that's a good action
jcraig: you can take this on and fill it out
jcraig: we can get you added to that project
jcraig: I could do it myself, but I want you all to do the work
jcraig: there's a readme in name that breaks down how the files are named
jcraig: there are some noops, but there are files for others, etc. etc.
jcraig: this is my readme of how I broke up accname into specific test files
jcraig: in wai-aria I want to point you at a few things. The role dir, which has a basic test. you can ignore the promise_test block. That's the original way to do it, but most tests don't use that, they use one of the convenience methods in AriaUtils
jcraig: I left the basic tests as a simple one that doesn't rely on that
jcraig: there's a readme in wai-aria, it's markdown, (reading the readme)
jcraig: you all should review the aria-utils.js if you're familiar with javascript in scripts/
jcraig: (talking through script) should keep complete list of roles in this file
live regions
<sarah_higley> jcraig: should keep a complete list of roles in this file
DG: Community feedback survey from Microsoft - voice of screen reader users, voice of deverlopers, voice of screen reader vendors
DG: Screen reader users were all Windows, would like input from other platforms
DG: also interviewed screen-reader vendors for deeper feedbak
DG: User feedback
DG: 1. Interruptions
DG: NVDA doesn't even represent Live Regions to Braille users
<DougGeoffray> Screen reader users are frustrated with irrelevant interruptions and want more control NVDA is filtering live regions from braille because of the overuse/misuse causing correctly used CoA to be missed Live regions are inconsistently implemented across browsers, screen readers, and web developers (have poor developer ergonomics) DOM-based notifications are buggy in a few ways: Inserting visually hidden live region text near the relevan[CUT]
<sarah_higley> (con't): Inserting visually hidden live region text near the relevant control means that text is separately discoverable by screen reader users with their virtual cursor. Site-wide live region systems often manage and insert live regions in a specific area of the DOM (often at the end), which can fail when users open a modal dialog. Difficult for screen readers to know how to expose the DOM information
<sarah_higley> Live Regions lack richness (no context, interpretation of how to build the string, and primitive prioritization) for screen readers. Developers are asking for a better answer than live regions for a reliable and consistent accessibility experience for users Screen reader developers want better guidance on what is expected behavior
<sarah_higley> Notification API: https://
<sarah_higley> google doc: https://
Matt_King: ARIA-AT says that it SR shouldn't say "alert". role=alert is the only way to get live region behavior across all browser/at
jcraig: role=timer is supposed to be aria-live=none, not announce unless focused, but not always implemented that way
DG: All screen-readers behave differently
DG: A programatic way to filter by notification type
<sarah_higley> https://
<sarah_higley> WICG/
DG: Goals of API
<sarah_higley> Improve end user experience: Consistent and predictable experience More control over what and how to consume notifications Filtering / Repeat / Jump to / Less disruptive Empower screen readers developers: Unambiguous string Context Grouping of notifications Improved Prioritization / interrupting guidance Empower web/browser developers: Offer an alternative to “offscreen live region” scena[CUT]
DG: Improve user experience, empower screen reader developers, empower web/browser developers
<sarah_higley> has easy-to-use developer ergonomics solves the consistency and predictability problems of live regions Provide a design framework for improvements to live regions as a “declarative version” of the notification API.
<sarah_higley> Notification API - Summary: New API ariaNotify() Allows authors to directly tell screen reader what to read No return value, no inference of assistive technology Independent arrays/queues Labels for screen reader context Processing recommendations / restrictions
<sarah_higley> Notifications are placed into a document or individual element arrays (Queues) The document, and each element in the DOM have separate pending notification arrays No guarantee which array is processed first Only guarantee is items within an array are processed in the given order Screen readers are not permitted to re-order the notifications within a p
<sarah_higley> (con't) Screen readers are not permitted to re-order the notifications within a pending notification array–they may only pull from the service end of such arrays
Matt_King: I don't think of things in a document as temporal. Is this a queue?
<Zakim> jcraig, you wanted to ask how this API solves some of the other use case problems you mentioned, such as how/where to act on the notification and to say, ah, the issue doesn't specify that this is on any element, not just document.
Matt_king: sent element bold on and then element bold off quickly (e.g. ctrl+b twice) - where does the first one go?
craig: There are things in the visual UI like a menu flash. Notification could come from the state change of the bold button.
jcraig: this javascript API would pass it's results to the relevant platform accessibility API.
DG: UIA, for example, has a rich notification API with more options that assertive|polite
Matt_King are these labels standardized tokens or a freeform string that will have to be standardized elsewhere
DG: token lists always fall short. screen readers already script for individual apps
jcraig: I'm not comfortable with screen readers talking directly to web pages
matt_king: explore something similar to role and role-description
<sarah_higley> Notification API - Labels: Each notification can have a label (unique or not) Labels provide context to the screen reader allowing users flexibility on how the notification is handled (filter / speech vs. braille / sound effects, etc.)
jamie: asking jcraig, is that really that different than voice-over custom labels?
jcraig: voice-over custom labels do filtering, not direct web page interaction
aaron: worried about proliferation. 15 chat programs shouldn't have 15 different behaviors for "user joins a chat". but now I'm ok with it, maybe standardize later
aaron: maybe call it somehthing other than label because it's not read to user
matt_king: so users can't block based on what they hear?
DG: block types of notification
jamesn: doesn't w3c have a place to put a list of conventions? Could use that for categories of notifications?
jcraig: notification calls are identified as task, progress, finished - but would be connected to a string like "file one downloaded"
jcraig: we should separate user-presented notification strings from system notifications (e.g. VoiceOver screen-changed notification is not exposed to user)
jcraig: context we've addressed in other ways with things like braille-description - should tweaks for different AT modalities be part of this
jcraig: started with lowest common denominator API, but now it seems like other types of notification use cases are piled on
DG: not sure why having more api is better?
DG: want to keep it simple and clear
jcraig: it seems less simple to have a bunch of different behaviors and a registry that's a parameter this seemingly simple api
cyns: API question: there is an interest tension, you can have an API that is seemingly simple, but if it has a huge list of "ids"
DougGeoffray: So you want an api that sends a string, and api that has specialized...
<spectranaut_> cyns: I think I'm trying to say this is not a simple API
jcraig: a simple one that just sends a string seems good for basic use case
jcraig: but if there's a different type of notification, like a system notification like a screen change, or a type of notification that users might want to suppress
adam_page: regarding potential proliferation, novice user might want to filter wihtout having to understand nuances of different types of notifications. Can we make isimpler for users to filter at a higher level
adam: user intent is different than interupt
DG: with screen-reader background, might have profiles for different apps and mapped into verbosity
cyns: built into browser so that less popular apps that there aren't scripts for seems better
matt_king: need to workshop these things individually with more time than we have here
matt_king: jcraig was talking about system notifications. I thought this wasn't for system events, just for things the web author thinks might need to be announced. Is it more general? How is it different than state chagne events and other stuff in core-aam?
DG: jcraig, are screen-change events coming from the web page of the system?
jcraig: when you change views, there's a UI Accessibility change event notification. Voiceover plays an earcon
jcraig: events in this doc are task start, task end, bold start, bold end (menu state change)
matt_king: from web author point of view looking at this api, are these things that are going to get spoken, or are they about other kinds of notifications
jcraig: api passes strings
matt_king: lets think about whether this should have different methods, and not complicate this for web authros
jamie: baseline for API is that we pass a string that should be announced. It can have parameters that user or AT vendor can choose to do something with it
jamie: this api is about announcing messages. first parameter should never be empty.
<jamesn> s/set the topic: aria live regions/topic: aria live regions/
jcraig: use ID to group announcements from one element, only play the last one, but not suppress all notifications
matt_king: if notification is on container, messages will be on the same element
matt_king: screen-reader should manage this
matt_king: only announce when it has focus
sarah_higley: I think we're getting a lot into how screen readers could use these IDs. Somehting with a lot of notifications like a chat app needs to be managed through the app. SR management should be more an out
sarah_higley: value here is for authors to be able to have an easy way to clear a que of certain types of messages. Not necessarily a way for end users to manage notifications
<Zakim> jcraig, you wanted to say remember this should not be specific to SRs
jcraig: not only for screen-readers - useful for other kinds of AT. Zoomed in with ZoomText or HoverText for example with an out-of-view visual notification, move the banner for the notification into your view
DG: back to the slides
DG: Notification API Array priorities
DG: insert message at beginning, end of array, clear array
matt_king: platform API needs to have the richness to manage it
cyns: where does this array live? In the browser? In the platform AAPI?
DG: in the platform AAPI
DG: Notification API - processing recommendations/restrictions slide
DG: Developer feedback to address
DG: should you support SSML? SR vendors nervous about that
DG: should it support braille strings? SR vendors - don't block on it
DG: SR vendors want better guidance, better docs
DG: Better maginifier interaction
DG: make queues easier to implement
DG: Call to Action
DG: does feedback resonate?
DG: more feedback - what about spam?
<Zakim> jamesn, you wanted to ask are we missing the simplest possible use case. Often we need a notification just to confirm that the action the user did actually succeeded. It really doesn't need a message. Is this something different?
jamesn: we hear from developers that they want to be able to announce task succes/failure
DG: guidance - if focus doesn't change, then announce
jamie: I have concerns about the array concept, too implementation specific
jamie: horrified by implementation example of custom list box. should just use aria
<jamesn> +1000
<Zakim> jcraig, you wanted to ask about the component scope of notifications, can one part of the page clear the queue from another part? and to address the "don't want to hold up the API" comment
jcraig: component scope of notifications. Should one component be able to clear notifications from another?
jcraig: let's be sure that we're launching something good, not just fast
DG: Can some features be in stages
<Zakim> cyns_, you wanted to ask about guidelines for AT
jcraig: as long as it's strucutred so that we can add things in a way that
matt_king: we are getting feedback in aria-at that guidance is helpful
jamie: it seems that the tone is chaging on that
Secondary Actions
sarah_higley: bit of an overview for folks who have’t followed along or forgotten
… secondary actions are additional actions on a primary action, such as a tabset, where tabs are the primary actions and [ Close tab ] are a secondary
… or a list item, with secondary actions of favorite, share, etc.
… or in MS Teams, a list of meeting participants, each one of which has secondary actions of mute, etc.
… in composite widget roles, there is currently no mechanism to add secondary operations
… you can’t have children interactive items, or non-interactive items in a menu
… there’s no reliable way to semantically create that UI
… there’s a recently merged PR to change the definition of “required owned element” and “required context role”
… define the specifics of what the DOM tree needs to look like for a menu
… e.g., a menu can’t be nested inside a listbox inside a menu
… there is explicitly no room to add an additional button inside the menu
… i also have a test page
… there are other use cases for this beyond composite widgets, such as video to mute/unmute, play/pause, etc. without needing to navigate to associated buttons
… there is a lot of discussion for this in issue #1440. There’s a draft PR #1805
w3c/
… context menu is not a substitute for secondary actions because 1) keyboard access is not universal, 2) does not solve visual/DOM presence of nested actions, 3) less discoverable
… for sighted users, secondary actions are often visibly much more discoverable
… in VoiceOver, the actions rotor could be a place for secondary actions to be surfaced, as one example
Jamie: Talkback also has an actions menu
Matt_King: it’s crazy hard to get to
Jamie: 100%
sarah_higley: aria-details is another thing that exists and is similar to secondary actions
… has browser and some screen reader support already
… the main difference between aria-actions and aria-details — similar in the abstract, but with different concrete UX needs
… so the proposal is `aria-actions="[id list]"`
… may reference any element with a widget role, exclude container roles (e.g. menuitem but not menu)
… controls references by aria-actions MUST be visible and activatable when the referencing element is focused or is the current active descendant of a focused element
… elements referenced by aria-actions do not participate in accname
… elements references by aria-actions are allowed children of their referencing element, or that element’s parents
… two options: 1) all nameable roles (with potential exceptions), 2) all elements of the base markup (with specific exceptions)
… not `presentation` or `none`, for example
… `generic` is an open question
Jamie: why do we need to change the naming spec? it feels like there could be cases where we do want them to be included in accname
… author in a tweet for example, becomes an action so you can get to that person
… why not aria-labelledby “yourself”
sarah_higley: the idea was name from content should just work
… vast majority of time, I’d expect you wouldn’t want them to participate in accname
… mute button would exist on every person in a meeting, for example
Matt_King: could we invert and recommend manual labeling when it’s desirable?
Jamie: yeah, understood, we just need to be sure we accommodate aria-labelledby
sarah_higley: yes, and it will only affect name from content
… the attribute is on the element whose accessible name it affects
<Zakim> jcraig, you wanted to react to cyns_
<Zakim> jcraig, you wanted to mention frozen element array element.ariaActionsElements
jcraig: in theory, this is futureproof for shadow DOM because reflected DOM property would be AriaActionsElements
… so two thumbs up from me
sarah_higley: yes, should reflect similarly to others
Matt_King: this might be controversial
… I’m leery of current scoping
… want to challenge “anything that is nameable”
… if we do that, and the action button that has to be visible, there are a lot of nameable containers that don’t get focus in any screen readers
… a landmark, for instance
… does that mean the custom action for that landmark is exposed on every single child?
sarah_higley: no
<Zakim> jamesn, you wanted to react to Matt_King
sarah_higley: take a dialog
… a dialog could have a close actions
… there’d still be a visible button
… like an alert dialog, or another dialog that has no interactive items
… so prohibiting aria-actions on dialogs _seems_ like a bad idea?
Matt_King: I’m leaning toward prohibiting in that case *would* be a good idea
… what’s the value to the screen reader user?
… elements that do the actions are things that are present and focusable
Jamie: it would be easier to prohibit for now and then add other use cases later
… address the use cases that we care about the most
Matt_King: exactly, be conservative here so we don’t have to backtrack
… I have another concern about screen readers that don’t change their virtual cursor focus
… if you have actions in a tablist on the tabs, and you’re reading through the tabs, where would focus go for one of those screen readers?
sarah_higley: it’s a tradeoff
… requiring all actions to be present in the DOM is a lot of weight
… especially for a grid, and goes against common interaction patterns
<Zakim> jcraig, you wanted to explain the "secondary" context and Matt's "prohibition"
jcraig: these are intended as “secondary” actions
… the actions rotor came about in iOS to expose some of these easy access methods that were accessible through some other means
… e.g., you’re in the Mail app on the phone. You can certainly go into the message to find secondary operations. But can be tedious, so we added gestures, etc. for easier exposure of those.
… the action rotor has the same intention
… a number of ways to get to the same action
… the intention is to be a convenience; not the *only* way to get to the action
… the bit about “prohibition” where I disagree is I want ARIA primitives that are simple to understand and simple to use
… fewer conditions for the author
… authors are going to make mistakes
… we shouldn’t design an API to be overly complicated so that only experts can figure out how to make it work
… the detail on how this action is exposed doesn’t require that a screen reader should be able to land on this container
… let’s say we’re in Gmail, I should be able to easily delete a focused message
… another example is a video container
… play/pause or change audio track is something you can do from anywhere within the container
… I like the idea of a primitive actions menu that works in any scenario
… there’ll always be some web author that comes up with a great example that could break our conditions
sarah_higley: I do have a slide for decisions to make which touches on this
scotto: you can’t put a button inside a button because the parser will just kick that button out
… there may need to be additional work with HTML
… not necessarily a parser change
… some sort of communication to let them know about a feature like this
… there is a potential feature or guidance that we need to consider bubbling up to the HTML spec
… so that when people do use this and they do try to misuse it, we should be able to explain why and what they should be doing instead
sarah_higley: in Office desktop, the font color “split button” — you press the button to change to the last chosen one, OR open a menu of all colors
… that’s kind of a button inside a button
Matt_King: the same way we have aria-selected, you can’t put it on all nameable elements. You could maybe make an argument that that policy was a mistake, but that’s the reality
… I look at this the same way
… I’m concerned about the idea that you could have aria-actions on an element that is spoken but not a navigable stop in the DOM
… and maybe this is the time to suggest that certain screen readers need to change how they behave
… but we’d need to pull them in
sarah_higley: I can see a potential SR mechanism for aria-actions. Right now it’s a semantic convenience, but you could have a SR key to pull up actions, similar to rotor, which would autofocus the control
… focusing the control could enable access to the secondary actions
… say you navigate to the primary action with your virtual cursor, the SR sees aria-actions, and can then present secondary actions
Jamie: for me the main question is — VO in iOS also doesn’t present landmarks as a navigable stop
… it worries me to allow something to be broad and then a situation where authors will say browser/AT aren’t complying with the spec, but they’re reasonably saying it’s impossible
… the fact we can’t spitball a good UX for this is a red flag
Jamie: we should start with a narrow, concrete use case and not be too permissive at first
jcraig: we’ve already got this video example, where the container has no role, but it would benefit from aria-actions, as broadly spec’d already
Jamie: well, video is an interactive thing
jamesn: we could limit it to interactive elements only
<Zakim> jcraig, you wanted to suggest this should change element continuations
sarah_higley: we could conceive a third policy option
jcraig: certainly this should not allow a literal <button> inside a <button>; aria-actions shouldn’t require a change to the HTML parser
sarah_higley: I do want to resolve this so that we can bring it to SR vendors
… and this will come up again later in the slides, so we can pick it up then
DougGeoffray: why does a SR user need to be notified that a secondary action exists?
jcraig: a sighted user can see these quickly, but a SR user otherwise would need to navigate around to know what’s available
Matt_King: there are situations where I’ve used the VO rotor feature and it _is_ useful, but there are also situations where it’s super confusing
… like in the case of email, if there could be actions on something that’s inside the email versus the email itself
Jamie: it also creates a lot of verbosity
… every single node in my email has an action on it, which can be deeply frustrating
… polluting the usefulness of an API. If everyone is seeing actions all the time, then it starts to become useless
sarah_higley: I’ll get through the rest, and then let’s come back to this
… Privacy
… jcraig and I discussed privacy implications at TPAC, but essentially our conclusion is that it does not introduce more risk than we already have
… for the underlying implementation, aaron can talk more about this
… but the proposal is that we can use the aria-details mapping
aaronlev: well, wanted to do that initially, but now am thinking it‘s too complicated
… so if we do it a nice, new, clean way, it’ll just be a bit longer for all users to have access to the feature
sarah_higley: this would be core-AAM and not ARIA
Matt_King: I think we’re gonna get good support for this out of the gate
Jamie: the mobile web sucks without this
jcraig: and we can already implement behind a flag without agreeing on all of the specific details
sarah_higley: nevermind on the aria-details mapping :-)
sarah_higley: another implementation detail is that we have an author SHOULD requirement for aria-keyshortcuts
… or a MUST aria-keyshortcuts _or_ some other keyboard access
… to expose keyboard activation hints
… for tabs in a context like VS Code, tab close buttons are not closeable
Jamie: I like this requirement
Matt_King: that’s not how aria-keyshortcuts works right now; currently, you put it on the target of the shortcut (i.e., the primary action)
Jamie: so better to have that on the secondary action targets
sarah_higley: let me pull up actual proposed wording
… my goal was not to be too prescriptive in how you access the secondary actions, just to ensure that there is keyboard operability
Matt_King: does the language say “the target action must be *focusable*?”
sarah_higley: no, need to be clickable but not focusable
… either need to 1) be able to navigate to it the DOM, or 2) activate it with keyboard
jcraig: re: privacy, the secondary actions must be visible and clickable to ensure that the API doesn't 'out' the user. Ideally it will look indistinguishable to the web app from a mainstream mouse click.
sarah_higley: aria-actions won’t require that secondary actions are descendants of the referring element
jcraig: one example: little hover buttons in Gmail; they need to be visible at the time they’re triggered
… alternative example, GitHub inbox: always visible bulk operation for multiple selected items in the inbox
Jamie: in that case, we do need to specify
… a practica example: social media
… you’ve got Like, Reply, React
… all these buttons after every single post
Matt_King: iOS Mail experience would be a great use case for us to put in the APG to clarify aria-actions usage and behavior
andrea_cardona: could you clarify the privacy concerns?
sarah_higley: we can’t have a situation where a SR user could activate a feature that a non-AT user *couldn’t*, otherwise they can be identified as an AT user
cyns: disability is sensitive PII
<Zakim> cyns, you wanted to ask if we should provide authors a way to specify the focus behavior if they want, and have a reasonable default that's controlled by either the browser or the AT?
cyns: maybe this proposal already covers this, but it sounds like we need a way for authors to specify how these show up, and a reasonable default if they don’t?
sarah_higley: yes
… it should be flexible
… if you wanted to avoid verbose announcement of actions, you could use aria-hidden
… but the *existence* of actions would still be announced
cyns: can this be made easier for developers as well as for their customers?
… seems like there’s an opportunity
Jamie: I agree
… I don’t think aria-hidden is the right solution
… if you manage to tab to something that’s aria-hidden, it’s not a good experience
… then we’d also need an entirely different way to implement, since aria-hidden is excluded from accessibility tree
… there needs to be a concept of “it’s not hidden, but it needs to be navigable”
Matt_King: the solution could be that it must be a descendant of the element?
jcraig: could be a non-default SR preference, like “automatically action elements that are also descendants”
jcraig: anytime we have an API that hides something as a side effect, authors get it wrong and hide things by accident
Matt_King: so what happens in the a11y tree if they are descendants? How does the reading order get calculated?
… if the SR was going to expose them?
… sounds complicated
… I have a tab that has two buttons inside of it. Does the SR present those both as descendants of the tab?
sarah_higley: yes, and invalid patterns like this are already in the wild
Jamie: aria-actions has the potential to make the mobile web in particular a lot better
… and we’ll need a robust way to allow for hiding of actions, to mitigate clutter
sarah_higley: I definitely agree that’s an issue, but not sure I buy that it’s directly related to aria-actions
Matt_King: I do wonder if there’s another attribute that we could put on the descendants to say whether or not they should be exposed
Jamie: it seems like 9 out of 10 times, you would not want it exposed, so I’m intrigued by the idea of another attribute to control that
sarah_higley: the thing that worries me is if *authors* decide when to hide things, versus SR vendors
cyns: what about a way for authors to hint?
sarah_higley: again, that seems related to aria-actions, but not limited to it — should be solved as a separate problem
Matt_King: right now, if you’re a web developer and you want to create iOS Mail on the web with a good SR experience, this doesn’t make it possible
jcraig: it does
jamesn: what actions are we taking up from this:
sarah_higley: things to follow up on:
… 1) nail down supported roles for referring and referenced elements
… 2) confirm whether to use aria-details platform mappings and implementation
… 3) get buy-in on full spec from browser and AT vendors
… 4) Web Platform Tests
… 5) and then this situation we’ve discussed about hiding secondary actions
Jamie: can we say that aria-hidden is off the table as a solution for #5?
sarah_higley: that was just one example
jcraig: it can’t be aria-hidden at the time I activate it, to paraphrase Jamie
… I do agree with that
Matt_King: I’m still wondering how that works in the a11y tree, seems like there’s a race condition
cyns: is the mechanism for switching between hidden and not hidden too complicated for developers, and can we make it easier?
sarah_higley: yes, that’s fair
<cyns> or is it good enough for V1