15:20:06 <RRSAgent> RRSAgent has joined #aria
15:20:10 <RRSAgent> logging to https://www.w3.org/2023/05/03-aria-irc
15:20:10 <Zakim> RRSAgent, make logs Public
15:20:11 <Zakim> please title this meeting ("meeting: ..."), jamesn
15:20:18 <jamesn> Meeting: ARIA WG F2F - Day 1
15:40:34 <jamesn> Q?
15:58:16 <Matt_King> Matt_King has joined #aria
15:59:16 <dmontalvo-mac> dmontalvo-mac has joined #aria
15:59:19 <BenBeaudry> BenBeaudry has joined #aria
15:59:26 <spectranaut_> spectranaut_ has joined #aria
15:59:35 <sarah_higley> sarah_higley has joined #aria
15:59:37 <Andrea> Andrea has joined #aria
16:04:39 <Adam_Page> Adam_Page has joined #aria
16:12:45 <jcraig> scribe: jcraig
16:12:57 <jcraig> Topic: What do. you want to work on this year for ARIA
16:16:14 <jcraig> spectranaut_: continue to work on testing for Core AAM and HTML AAM
16:16:25 <jcraig> continuing to improve the contribution process
16:16:38 <jcraig> Andrea:
16:17:01 <jamesn> zakim, who is on the call?
16:17:01 <Zakim> Present: (no one)
16:17:10 <jcraig> s/Andrea: /Andrea: would love to help with contributing process/
16:17:34 <jcraig> Adam_Page: open PRs, aria-actions, WPT
16:17:49 <jcraig> sarah_higley: taking Adam_Page's freetime
16:18:08 <jcraig> sarah_higley: aria-actions, interactive lists, etc
16:18:33 <spectranaut_> sarah's interactive lists: https://github.com/w3c/aria/issues/1884#issuecomment-1533166368
16:19:00 <jcraig> Matt_King: aria features: aria-actions, live regions and notifications, and finally dialog, in particular particularly non-modal or modeless dialogs
16:20:08 <jcraig> Matt_King: working on process to get both practices and WPT tests landed simultaneously with the spec change...
16:20:24 <spectranaut_> Matt_King also mentioned ARIA-AT tests
16:21:10 <jcraig> dmontalvo: 1.2 Rec process, ARIA-AT showing results now
16:21:54 <jcraig> cyns: interactive elements in general, in particular, AOM incubations, Open UI, overlap with ARIA, etc
16:22:27 <jcraig> cyns: Chrome implemementations, finding gaps between implementations, bringing more Googlers into the process of contributing
16:22:53 <scotto> scotto has joined #aria
16:23:26 <jcraig> 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
16:24:02 <jcraig> DG: constantly hearing things like "the web doesn't do that".... Most web apps have very poor accessibility
16:24:26 <jcraig> DG: Would love to get the richness of desktop accessibility to the web
16:25:11 <jcraig> BenBeaudry: Live Regions, pushing in Edge and Chromium. New to this group, but not to Accessibility (in Chrome, etc)
16:25:28 <jcraig> BenBeaudry: want to push my boundaries to contribute to the design process...
16:25:59 <jcraig> BenBeaudry: all platforms... Mobile, Linux, etc. the web is the equalizer
16:26:25 <jcraig> BenBeaudry: need to rebuild expertise lost from people that have left recentlyt
16:26:43 <BenBeaudry> scribe: BenBeaudry
16:27:14 <cyns> cyns has joined #aria
16:27:54 <BenBeaudry> 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
16:28:06 <BenBeaudry> jcraig: just the tip of the iceberg
16:28:50 <BenBeaudry> jcraig: a related area I'm interested about is find a path forward for enabling all these tests and allow for relationships between nodes
16:29:09 <BenBeaudry> jcraig: more to discuss in the meeting tomorrow
16:29:12 <jcraig> scribe: jcraig
16:29:30 <jcraig> jamesn: excited about live regions.... likely a replacement
16:30:15 <jcraig> improvements to tables and grids... even HTML tables... would love to be able to do everything we need to for complex web apps
16:30:21 <jcraig> accesible dataviz
16:30:32 <jcraig> s/accesible/accessible/
16:31:05 <scotto> scotto has joined #aria
16:31:41 <jcraig> scotto: aria-actions and interactive lists.... composite widgets. fixing the implementation and UI paths
16:32:13 <jcraig> getting clarity around modeless/non-modal dialogs.... Notification API, etc
16:32:35 <jcraig> Agree with jamesn that a notification API can coexist with Live Regions
16:33:14 <jcraig> Open UI scope: are there new ways to think about old patterns like list boxes... Are there better patterns we could promote instead?
16:34:28 <jcraig> Siri: interested in polishing patterns/widgets like tables/grids
16:34:43 <jcraig> not well supported in all screen readers
16:35:32 <jcraig> determining commonly used widgets and patterns, to tackle the interaction problems
16:36:49 <jcraig> Rashmi: mostly how ARIA interacts with screen readers. Correcting the edge case problems.
16:37:15 <siri> siri has joined #aria
16:37:19 <jcraig> spectranaut_: summarizing
16:38:15 <jcraig> focusing on the list that aren't slotted for discussion in this F2F
16:38:24 <jcraig> ARIA-AT tests
16:38:30 <jcraig> validation tests
16:39:36 <cyns> Q+ to ask if we can put links to the various tests suites into the minutes?
16:39:38 <jcraig> exposure of more surface than currently testable
16:39:54 <jcraig> how to bring the richness of native to the web
16:40:15 <jcraig> polish of old patterns, and anti-patterns... Open UI is working on this to some degree
16:40:40 <jcraig> specific examples: interactive lists, tables and grids, dataviz, etc.
16:40:56 <jcraig> normalizing platform differences
16:41:18 <jamesn> q+
16:41:18 <jcraig> how to facilitate and mentor the next generation and make sure knowledge isn't lost
16:41:47 <spectranaut_> documentation: https://github.com/w3c/aria/blob/main/documentation/tests.md
16:42:03 <jcraig> and https://github.com/w3c/aria/blob/main/documentation/wpt.md
16:42:22 <jamesn> ack cyns
16:42:22 <Zakim> cyns, you wanted to ask if we can put links to the various tests suites into the minutes?
16:42:29 <jcraig> cyns: old Edge tests not yet landed in WPT
16:42:54 <jamesn> ack me
16:43:25 <jcraig> jamesn: in terms of getting mentorship and new blood, I'm talking to A11yCamp Bay on Friday
16:44:00 <jcraig> open to suggestions for exciting topics to share
16:44:50 <jcraig> DG: re: live regions, devs will *think* they have written Live Regions well... How do they know? Are these in those tests?
16:44:52 <jcraig> q+
16:44:58 <jamesn> q+
16:45:13 <jcraig> Matt_King: ARIA-AT has manual tests for all manner of Live Region tests
16:45:28 <jcraig> Much is left up to implementations...
16:45:46 <jcraig> APG only has 3 or 4 Live Region tests?
16:46:20 <jcraig> Scott and Sarah also have live regions tests
16:46:28 <jamesn> q?
16:47:07 <jcraig> DG: devs may be hesitant to throw excess notifications if they could see the excess of text thrown at the user
16:47:35 <jcraig> Matt_King: back-burner project... simplified accessibility tree and events would be a good visualization
16:47:42 <cyns> Old Edge WPT UIA Implementation tests for HTML https://github.com/MicrosoftEdge/a11y
16:47:55 <jcraig> q?
16:48:01 <cyns> IIRC there were ARIA tests at one point, but they may be lost the sands
16:48:06 <cyns> q+
16:48:15 <jcraig> Matt_King: including live region "flashes"
16:48:59 <jcraig> jamesn: start with a UI for the tree
16:49:17 <spectranaut_> q?
16:49:23 <jamesn> ack jcraig
16:49:52 <sarah_higley> q+
16:51:03 <cyns> Demo of Chrome Dev Tools A11y Tree viewer https://io.google/2022/program/84bda4d4-bdd9-418f-aa85-f6adbc9f50d8/
16:53:03 <jamesn> ack me
16:53:26 <jcraig> jcraig: @@@
16:54:02 <jcraig> jamesn: standards and wcag can be to blame for testers thinking verbosity needs to be high
16:54:54 <jcraig> re: live regions: don't overcomplicate the notification API with a requirement for Live region completeness
16:55:36 <sarah_higley> ack me
16:55:40 <jcraig> cyns: screen reader visualizer experience, could recruit others to build it
16:56:13 <jcraig> sarah_higley: visualizer could show when speech jobs get trampled with live regions
16:56:24 <jcraig> and other interaction problems
16:56:42 <jcraig> .... edge cases re: live region queing
16:56:51 <jcraig> s/queing/queueing/
16:56:59 <sarah_higley> ack me
16:57:13 <jamesn> q?
16:57:19 <spectranaut_> ack cyns
16:57:36 <DougGeoffray> DougGeoffray has joined #aria
16:57:40 <Adam_Page> Adam_Page has joined #aria
16:58:05 <DougGeoffray> present+
16:58:14 <jamesn> present+
16:58:26 <jcraig> spectranaut_: will make a visualizer dev tools issue in the tracker
16:58:33 <scotto> present+
17:02:23 <jcraig> spectranaut_: jamesn what about fixing tables
17:03:28 <jcraig> jamesn: wanted for a long time, particularly large tables offloaded to the servers, sectioning scrolls out of view, editable cells, virtualization…
17:04:10 <scotto> big +1 to how to exposed 'virtualized' content in a better way
17:04:11 <jcraig> trying to keep focus in the right part of the table while the virtualized tables are being re-rendered
17:04:12 <sarah_higley> q+
17:04:59 <jcraig> ack sarah_higley
17:05:27 <sarah_higley> ack me
17:05:38 <jcraig> sarah_higley: virtualization of tables should consider lists and other container types
17:06:12 <BenBeaudry> q+
17:07:33 <jcraig> Aaron: including more things in HTML, like keyboard interaction by default rather than accessibility-specific interfaces, so devs don't have to specialize
17:07:51 <Matt_King> Virtualization proposal https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/VirtualContent/explainer.md
17:08:33 <jcraig> BenBeaudry: Matt_King was talking about ARIA virtual content.... I implemented support in Chromium. needed SR support
17:08:35 <spectranaut_> ack BenBeaudry
17:08:58 <jcraig> DG: concerns re: performance
17:09:03 <jcraig> q+
17:09:08 <BenBeaudry> q-
17:09:09 <scotto> q+
17:09:23 <jcraig> Matt_King: read through this before the meeting time tomorrow
17:10:01 <BenBeaudry> q?
17:10:13 <jcraig> cyns: accessibleObject (abandoned API ) behind a flag in Chrome
17:10:25 <spectranaut_> scribe: spectranaut_
17:11:31 <cyns> q+
17:11:45 <jamesn> zakim, close the queue
17:11:45 <Zakim> ok, jamesn, the speaker queue is closed
17:12:00 <spectranaut_> 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 killed many new ideas.
17:12:39 <spectranaut_> q?
17:12:41 <jamesn> ack jcraig
17:12:43 <jamesn> ack scotto
17:13:03 <jcraig> s/this has killed many new ideas./this has made it difficult to explore many new ideas./
17:13:19 <jcraig> scotto: consider attribute parity with HTML
17:13:27 <Matt_King> q+
17:13:59 <jcraig> HTML has a partial solution to virtualization with the lazy attributes.... What if we leveraged existing or created new HTML features
17:14:19 <jamesn> ack cyns
17:15:28 <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
17:16:33 <jcraig> jamesn: BREAK until 10:30 AM Pacific (14m)
17:33:51 <dmontalvo-mac> dmontalvo-mac has joined #aria
17:34:42 <jcraig> s/jcraig: @@@/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./
17:35:20 <jamesn> zakim, open the queue
17:35:20 <Zakim> ok, jamesn, the speaker queue is open
17:36:17 <jamesn> TOPIC: Introduction/Overview of Automated Testing
17:36:27 <jamesn> https://github.com/w3c/aria/issues/1879
17:37:04 <sarah_higley> scribe: sarah_higley
17:38:15 <Adam_Page> Adam_Page has joined #aria
17:42:23 <sarah_higley> 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
17:42:40 <sarah_higley> 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
17:42:48 <sarah_higley> jcraig: ask questions, feel free to interrupt
17:43:39 <andrea_cardona> andrea_cardona has joined #aria
17:43:51 <sarah_higley> 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
17:44:14 <sarah_higley> 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
17:44:44 <sarah_higley> 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
17:45:08 <sarah_higley> 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
17:45:19 <sarah_higley> jcraig: it handles a bunch of background API like XHR requests, etc.
17:45:46 <sarah_higley> 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
17:46:22 <sarah_higley> 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.
17:46:44 <sarah_higley> jcraig: switch controls, screen readers, ATs interface with that and present it to the user.
17:47:02 <sarah_higley> Matt_King: on these slides do you have graphical representations?
17:47:06 <sarah_higley> jcraig: yes, want more detail?
17:47:19 <sarah_higley> Matt_King: no, I've had to explain the same stuff to other non-accessibility people, wondering if the slides are shareable
17:47:27 <sarah_higley> jcraig: I can share a PDF version of this
17:47:36 <sarah_higley> jcraig: let me double check
17:47:55 <dmontalvo-mac> q+
17:48:04 <sarah_higley> Matt_King: I imagine there's other people who also need to explain this
17:48:05 <sarah_higley> (general agreement)
17:48:28 <sarah_higley> 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
17:48:34 <sarah_higley> jcraig: I"ll explain the web automation stack next
17:48:52 <sarah_higley> jcraig: started with platform-specific automation. This is why UIA is named UI Automation. Apple has its own automation framework
17:49:15 <sarah_higley> jcraig: now a native app dev would use something like XCUI tests for XCode tests, these leverage the platform a11y api
17:49:48 <sarah_higley> 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
17:49:52 <jamesn> q?
17:50:03 <sarah_higley> jcraig: likewise, most people probably thought of these client automation tools like axe-core.
17:50:13 <sarah_higley> spectranaut_: we call these the validator tests
17:50:29 <sarah_higley> jcraig: does your DOM structure comply with WCAG, these sort of things
17:50:42 <sarah_higley> jcraig: WebDriver, Selenium started off as this sort of thing as well before they moved into the browser
17:50:52 <jamesn> Ack dmontalvo-mac
17:51:25 <sarah_higley> jcraig: for Windows there's another little arrow I'm missing that comes from this AT over here into the WebCore implementation
17:51:32 <sarah_higley> jcraig: it doesn't work that way on mac, but it does on Windows
17:51:46 <sarah_higley> Matt_King: JAWS is using IA2 and UIA and MSAA, they're not processing the DOM
17:51:50 <sarah_higley> jcraig: let's not divert into that
17:52:01 <sarah_higley> jcraig: those are the two platform-specific, client automation
17:52:35 <sarah_higley> 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)
17:52:57 <sarah_higley> jcraig: all these engines are duplicating the work. Webkit, Chromium, Gecko, all have these thousands of tests
17:53:25 <sarah_higley> jcraig: sounds like a lot, until you realize how web platform tests has 1.8mil tests
17:53:44 <sarah_higley> jcraig: Up until now the only a11y things they were doing crash tests. Val added these IDL tests for ARIA
17:54:08 <sarah_higley> jcraig: someone wrote those in the past year or two. Not testing the accessibility internals, only testing that this works
17:54:22 <sarah_higley> jcraig: look up Acid3 tests, with a weird css smiley face
17:54:39 <sarah_higley> jcraig: that wasn't specific to a11y. But all the automation tests are in these LayoutTests
17:54:53 <sarah_higley> jcraig: the cross-browser automation project is a collab between w3c and a whole lot of other entitites
17:55:11 <sarah_higley> jcraig: 1.8 million tests, with a whole bunch of features. Shadow DOM, css, etc. Not a lot about a11y
17:55:24 <sarah_higley> jcraig: been around for about 10 years, only 3 years ago they started this project called Interop
17:55:45 <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.”
17:56:12 <jcraig> https://wpt.fyi/interop-2023
17:56:17 <sarah_higley> Matt_King: what does works exactly the same mean?
17:56:18 <sarah_higley> jcraig: heh
17:56:26 <sarah_higley> jcraig: I'll come back to that in a demo
17:56:40 <sarah_higley> jcraig: this (graph) was as of this week or last week. Webkit and Edge keep leapfrogging eachother
17:56:56 <sarah_higley> jcraig: there are lines for each of the different implementations up until May, now
17:57:04 <sarah_higley> jcraig: Chrome, firefox, safari, and interop
17:57:21 <sarah_higley> jcraig: axes are months in 2023, Y is percentage towards 100
17:57:32 <sarah_higley> jcraig: this is a selection of features that devs agreed on we would work towards interop this year
17:57:43 <sarah_higley> jcraig: the interop line is lower than the browsers, at 73% passing interop
17:58:09 <sarah_higley> jcraig: the features include inert, flexbox, etc. 73% of those are passing in all implementations
17:58:23 <sarah_higley> jcraig: the browsers are in the high 90s, interop in high 80s at end of last year
17:58:34 <sarah_higley> jcraig: we all compete to be the best and work together along the way
17:58:53 <sarah_higley> jcraig: someone said let's get a standardized a11y tree, and everyone said that's not gonna happen but love the enthusiasm
17:58:58 <sarah_higley> jcraig: so working together to get more a11y testing
17:59:41 <sarah_higley> 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
18:00:22 <sarah_higley> 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
18:00:30 <sarah_higley> jcraig: it still uses webdriver behind the scenes, but makes it a lot easier to write tests
18:00:39 <sarah_higley> jcraig: literally one line of js
18:01:06 <sarah_higley> 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
18:01:21 <sarah_higley> jcraig: (listing browser passing numbers)
18:01:31 <sarah_higley> jcraig: all hitting around 90% of these tests
18:01:53 <sarah_higley> 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
18:02:04 <jcraig> Cite:  https://wpt.fyi/results/?label=master&label=experimental&aligned&q=path:/accessibility or path:/accname or path:/html-aam or path:/wai-aria or path:/html/dom/aria-element-reflection.html
18:02:45 <jcraig> https://wpt.fyi/results/?label=master&label=experimental&aligned&q=path%3A%2Faccessibility%20or%20path%3A%2Faccname%20or%20path%3A%2Fhtml-aam%20or%20path%3A%2Fwai-aria%20or%20path%3A%2Fhtml%2Fdom%2Faria-element-reflection.html
18:03:22 <sarah_higley> jcraig: this is a subview in these tests inside the WAI ARIA tests
18:03:44 <sarah_higley> 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
18:04:08 <sarah_higley> 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
18:04:30 <sarah_higley> jcraig: benefits are that literally thousands of a11y tests are now unblocked. Specifically computedRole and ComputedLabel, but there are thousands with those
18:04:48 <sarah_higley> jcraig: bugs have been discovered and resolved in webkit, chromium, and gecko. Also found spec ambiguities
18:05:21 <sarah_higley> 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
18:05:32 <sarah_higley> jcraig: but spec authors and w3c contribs had incentives to write it
18:06:27 <sarah_higley> 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
18:06:35 <sarah_higley> jcraig: so it's a lot of incentive for the web devs to take over this
18:07:17 <sarah_higley> 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
18:07:45 <sarah_higley> 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
18:07:49 <jcraig> https://github.com/WICG/aom/issues/197
18:08:05 <sarah_higley> jcraig: the AOM issue is computed accessible node
18:08:14 <jamesn> Q?
18:08:15 <Matt_King> q?
18:08:52 <sarah_higley> 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
18:09:18 <sarah_higley> jcraig: let's go into demos
18:09:40 <sarah_higley> jcraig: WPT github dashboard
18:10:07 <sarah_higley> 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
18:10:23 <Adam_Page> Adam_Page has joined #aria
18:10:37 <sarah_higley> 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
18:10:53 <sarah_higley> jcraig: there will be more in here for svg-aria and svg-aam, but those are draft PRs now
18:11:01 <sarah_higley> Matt_King: what are those in the a11y folder, e.g. crash tests
18:11:12 <sarah_higley> jcraig: those are specific crashes that occured during implementation
18:11:21 <sarah_higley> spectranaut_: Aaron wrote them!
18:11:48 <sarah_higley> 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
18:11:58 <sarah_higley> jcraig: I have this search query to get all teh current a11y tests, I pasted in earlier
18:12:26 <sarah_higley> 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
18:12:30 <sarah_higley> jcraig: and the new aria tests too
18:12:46 <sarah_higley> jcraig:  if you dig into accname or aria you see a manual dir. I put them there because they're not being maintained
18:12:52 <sarah_higley> spectranaut_: they are being maintained by me
18:12:55 <sarah_higley> jcraig: you run them?
18:13:08 <sarah_higley> spectranaut_: yeah, we have hacked-together tools to run them. It's a long story for another day
18:13:15 <sarah_higley> jcraig: OK, valerie is running the one implementation
18:13:21 <sarah_higley> spectranaut_: only html-aam and core-aam
18:13:33 <sarah_higley> jcraig: that's the thing that runs the client server and etc etc?
18:13:48 <sarah_higley> spectranaut_: no actually, I have to look at the manual tests in ARIA, nvm. I was thinking about html-aam and core-aam
18:13:57 <sarah_higley> jcraig: the stack to set it up is really complicated
18:14:04 <sarah_higley> spectranaut_: the html-aam and core-aam are maintained
18:14:20 <sarah_higley> jcraig: anyway they're manual and not run by the dashboard implementation
18:14:50 <sarah_higley> 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
18:15:10 <tzviya> tzviya has joined #aria
18:15:15 <sarah_higley> 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
18:15:50 <sarah_higley> 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
18:15:58 <sarah_higley> jcraig: increased cursor size makes it easier to see
18:16:09 <sarah_higley> jcraig: showing us all his computer display settings
18:16:24 <sarah_higley> jcraig: cursor doesn't show up on the shared screen! New bug to file
18:16:40 <sarah_higley> jcraig: in details, see associated bugs
18:17:06 <sarah_higley> 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
18:17:12 <sarah_higley> jcraig: don't do it unless you're sure that's the right bug
18:17:18 <sarah_higley> jcraig: in html-aam tests --
18:17:52 <sarah_higley> 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
18:18:00 <sarah_higley> jcraig: so this is how the dashboard works in WPT
18:18:04 <jamesn> Q?
18:18:19 <sarah_higley> jcraig: next is interop a11y investigation. This is a github project, check the issues list. Issue 3 is the scoring criteria
18:18:45 <sarah_higley> 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
18:19:00 <sarah_higley> jcraig: remaining portions are all based on writing these tests and getting them running. A handful are completed
18:19:11 <sarah_higley> jcraig: all these other tests in accname and role are things you all can take
18:19:25 <sarah_higley> jcraig: tried to separate them out so it's easy for someone to take them on as an issue and PR
18:19:43 <sarah_higley> jcraig: some of the other things include things like computed parent and children, that's an AOM issue
18:20:18 <sarah_higley> 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
18:20:50 <sarah_higley> 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
18:21:28 <sarah_higley> jcraig: (listing issues in accname)
18:21:42 <sarah_higley> jcraig: there are running tests for these, but they're usually just a single test
18:21:53 <sarah_higley> jcraig: interop 2023 dashboard
18:22:19 <sarah_higley> jcraig: I mentioned the diff between focus areas and implementation areas.
18:22:32 <sarah_higley> jcraig: inert is at 100%, wooooooooo
18:22:46 <sarah_higley> jcraig: as of the most recent Safari tech preview, we're at 100% inert tests
18:22:53 <sarah_higley> jamesn: does that mean we're not testing enough?
18:22:55 <sarah_higley> jcraig: probably
18:23:11 <sarah_higley> jcraig: in stable inert is still down at 94%, because of safari. But at experimental has 100%
18:23:27 <sarah_higley> jcraig: in a11y testing you can see the investigation is at 60% and that's based on that earlier criteria
18:23:39 <sarah_higley> jcraig: chrome jumped ahead, (reading %'s of each browser in dashboard)
18:23:50 <sarah_higley> jcraig: I'm going to run some tests now
18:24:01 <sarah_higley> jcraig: and then show some tests, because I think that's powerful as well
18:25:02 <sarah_higley> jcraig: (running accname tests in fully white terminal with black text on screen)
18:26:59 <sarah_higley> (now jcraig has a black terminal with green text)
18:27:08 <sarah_higley> spectranaut_: old hacker imagery
18:27:24 <sarah_higley> jcraig: back on topic
18:27:50 <sarah_higley> jcraig: so there's going to be a bunch of spew on screen, most of it is normal
18:28:07 <sarah_higley> jcraig: it's popping up browser windows, running tests in the accname dir, it's completed now
18:28:32 <sarah_higley> jcraig: the important part here is this bock of text saying ran X checks, subtests, tests. Expected results 31, unexpected results 1
18:28:40 <sarah_higley> jcraig: that matches the dashboard, so that's accurate
18:29:13 <sarah_higley> 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
18:29:45 <sarah_higley> jcraig: this is running locally on my machine, on my copy of chrome and my copy of safari tech preview
18:29:57 <sarah_higley> Matt_King: so you can only test things on your machine? not the windows version?
18:30:05 <sarah_higley> jcraig: this should be the same because it's testing browser internals
18:30:17 <sarah_higley> jcraig: I'm just going to run one of these, the one that failed
18:30:25 <sarah_higley> jcraig: which test failed is in the logout
18:30:29 <sarah_higley> jcraig: running that with the test path
18:30:45 <sarah_higley> jcraig: the difference will be that it pauses that test in the window with it open
18:30:52 <sarah_higley> jcraig: running one a time pauses with the window open
18:31:31 <sarah_higley> jcraig: you get a popup when you try to interact with a window controlled by automation
18:32:33 <sarah_higley> (jcraig being evil and making people guess what to click in the popup)
18:33:20 <sarah_higley> jcraig: you all should read the documentation tonight
18:33:47 <sarah_higley> jcraig: click stop session in the dialog
18:34:11 <sarah_higley> jcraig: (reading message in the test details)
18:35:38 <sarah_higley> 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
18:36:03 <sarah_higley> 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
18:36:30 <sarah_higley> jcraig: in order to inform that discussion I wrote a PR with a new test. (showing the PR diff)
18:37:06 <sarah_higley> jcraig: I put in what webkit is returning in data-expectedrole. The script is AriaUtils.verifyRoleBySelector
18:37:22 <sarah_higley> jcraig: it compares the computed role (not the role) against what I defined as the expected role
18:37:48 <sarah_higley> 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.
18:38:09 <sarah_higley> jcraig: I click on the results from safari, and you can see 3/3 passed, there's a visual comparison of the results
18:38:17 <sarah_higley> jcraig: before the tests there were no results, after the tests all three pass
18:38:43 <sarah_higley> jcraig: going back to chrome's view, 0/3 passed in the visual comparison
18:38:50 <Adam_Page> Adam_Page has joined #aria
18:39:01 <sarah_higley> jcraig: if you click show details you get the entire fail message, including markup and expectation vs. result
18:39:10 <sarah_higley> jcraig: so this is an area where the spec is ambiguous
18:39:41 <sarah_higley> 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
18:40:05 <sarah_higley> 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
18:40:21 <sarah_higley> jcraig: try to get your machine configured tonight, I"ll paste in docs links
18:40:31 <jcraig> https://github.com/w3c/aria/blob/main/documentation/wpt.md
18:40:59 <sarah_higley> jcraig: this is what worked for me on my mac, the second link has more info for other systems
18:41:17 <sarah_higley> jcraig: (going through the info in the doc)
18:42:12 <sarah_higley> jcraig: there's a lot of documentation not in the wiki, but in the source itself.
18:42:22 <sarah_higley> jcraig: in accessibility, in addition to crash tests there's a readme
18:42:31 <sarah_higley> jcraig: it says not to use this directory
18:43:11 <sarah_higley> 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
18:43:21 <sarah_higley> jcraig: lots of files for comp_tooltip, etc
18:43:29 <sarah_higley> jcraig: embedded control was failing, let's look
18:43:51 <sarah_higley> jcraig: in the file there are a lot of TODOs, that's a good action
18:43:57 <sarah_higley> jcraig: you can take this on and fill it out
18:44:10 <sarah_higley> jcraig: we can get you added to that project
18:44:47 <sarah_higley> jcraig: I could do it myself, but I want you all to do the work
18:45:03 <sarah_higley> jcraig: there's a readme in name that breaks down how the files are named
18:45:26 <sarah_higley> jcraig: there are some noops, but there are files for others, etc. etc.
18:45:36 <sarah_higley> jcraig: this is my readme of how I broke up accname into specific test files
18:46:13 <sarah_higley> 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
18:46:22 <sarah_higley> jcraig: I left the basic tests as a simple one that doesn't rely on that
18:46:44 <sarah_higley> jcraig: there's a readme in wai-aria, it's markdown, (reading the readme)
18:47:24 <sarah_higley> jcraig: you all should review the aria-utils.js if you're familiar with javascript in scripts/
18:47:53 <sarah_higley> jcraig: (talking through script)
18:48:13 <sarah_higley> jcraig: should keep a complete list of roles in this file
18:51:12 <Adam_Page> Adam_Page has joined #aria
18:51:16 <dmontalvo-mac> dmontalvo-mac has joined #aria
20:04:57 <Adam_Page> Adam_Page has joined #aria
20:05:21 <dmontalvo-mac> dmontalvo-mac has joined #aria
20:09:34 <sarah_higley> sarah_higley has joined #aria
20:10:48 <cyns> cyns has joined #aria
20:11:25 <cyns> cyns has changed the topic to: aria live regions
20:12:37 <cyns> DG: Community feedback survey from Microsoft - voice of screen reader users, voice of deverlopers, voice of screen reader vendors
20:12:46 <andrea_cardona> andrea_cardona has joined #aria
20:13:07 <cyns> DG: Screen reader users were all Windows, would like input from other platforms
20:13:24 <cyns> DG: also interviewed screen-reader vendors for deeper feedbak
20:13:38 <cyns> DG: User feedback
20:13:47 <cyns> DG: 1. Interruptions
20:14:24 <cyns> DG: NVDA doesn't even represent Live Regions to Braille users
20:14:32 <BenBeaudry> BenBeaudry has joined #aria
20:14:53 <BenBeaudry> present+
20:15:46 <Rashmi__> Rashmi__ has joined #aria
20:16:02 <DougGeoffray> DougGeoffray has joined #aria
20:16:07 <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]
20:17:24 <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 ​
20:17:34 <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
20:19:15 <sarah_higley> Notification API: https://wicg.github.io/aom/notification-api.html
20:19:23 <sarah_higley> google doc: https://docs.google.com/document/d/17kKNoCIoMSFMFicz0wSQR-PHWHfHGYfz1WdtHMYyrhE/edit?usp=sharing
20:21:02 <Adam_Page> Adam_Page has joined #aria
20:21:30 <cyns> Q+ to ask if there are differences in experience with roles that are live (e.g alert, status) vs adding aria-live attribute
20:23:04 <cyns> 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
20:23:51 <cyns> jcraig: role=timer is supposed to be aria-live=none, not announce unless focused, but not always implemented that way
20:24:23 <cyns> DG: All screen-readers behave differently
20:24:48 <cyns> DG: A programatic way to filter by notification type
20:25:10 <sarah_higley> https://github.com/WICG/aom/issues
20:25:18 <sarah_higley> https://github.com/WICG/aom/issues/187
20:26:09 <spectranaut_> q?
20:26:18 <cyns> DG: Goals of API
20:26:23 <cyns> q-
20:26:56 <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]
20:27:02 <cyns> DG: Improve user experience, empower screen reader developers, empower web/browser developers
20:27:11 <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.
20:29:34 <jamesn> q?
20:29:55 <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
20:30:48 <jcraig> q+ to ask how this API solves some of the other use case problems you mentioned, such as how/where to act on the notification
20:31:05 <sarah_higley> sarah_higley has joined #aria
20:31:07 <Siri> Siri has joined #aria
20:31:24 <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
20:31:32 <jcraig> q+ to say, ah, the issue doesn't specify that this is on any element, not just document.
20:31:33 <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
20:33:25 <cyns> Matt_King: I don't think of things in a document as temporal. Is this a queue?
20:33:44 <jamesn> ack jcraig
20:33:44 <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
20:33:47 <Zakim> ... specify that this is on any element, not just document.
20:36:30 <cyns> Matt_king: sent element bold on and then element bold off quickly (e.g. ctrl+b twice) - where does the first one go?
20:37:28 <Jamie> q+
20:37:41 <cyns> craig: There are things in the visual UI like a menu flash. Notification could come from the state change of the bold button.
20:38:11 <cyns> jcraig: this javascript API would pass it's results to the relevant platform accessibility API.
20:38:55 <cyns> DG: UIA, for example, has a rich notification API with more options that assertive|polite
20:39:26 <jcraig> https://developer.apple.com/documentation/uikit/uiaccessibilityannouncementnotification?language=objc
20:40:20 <Jamie> q-
20:40:55 <jcraig> https://developer.apple.com/documentation/appkit/nsaccessibilityannouncementrequestednotification?language=objc
20:41:44 <cyns> Matt_King are these labels standardized tokens or a freeform string that will have to be standardized elsewhere
20:42:20 <cyns> DG: token lists always fall short. screen readers already script for individual apps
20:43:03 <cyns> jcraig: I'm not comfortable with screen readers talking directly to web pages
20:43:21 <jcraig> q+ aaron
20:43:22 <cyns> matt_king: explore something similar to role and role-description
20:43:36 <jamesn> q+
20:44:17 <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.)
20:44:21 <cyns> jamie: asking jcraig, is that really that different than voice-over custom labels?
20:45:06 <cyns> jcraig: voice-over custom labels do filtering, not direct web page interaction
20:45:45 <jcraig> q+
20:45:51 <jcraig> ack aar
20:45:59 <cyns> 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
20:46:22 <cyns> aaron: maybe call it somehthing other than label because it's not read to user
20:46:26 <jamesn> q?
20:46:45 <cyns> matt_king: so users can't block based on what they hear?
20:46:58 <jamesn> ack me
20:47:02 <cyns> DG: block types of notification
20:47:50 <cyns> jamesn: doesn't w3c have a place to put a list of conventions? Could use that for categories of notifications?
20:48:19 <cyns> q+
20:48:37 <Adam_Page> q+
20:49:51 <cyns> jcraig: notification calls are identified as task, progress, finished - but would be connected to a string like "file one downloaded"
20:50:32 <cyns> jcraig: we should separate user-presented notification strings from system notifications (e.g. VoiceOver screen-changed notification is not exposed to user)
20:51:08 <Matt_King> q?
20:51:19 <Matt_King> q+
20:51:26 <cyns> jcraig: context we've addressed in other ways with things like braille-description - should tweaks for different AT modalities be part of this
20:52:24 <cyns> jcraig: started with lowest common denominator API, but now it seems like other types of notification use cases are piled on
20:52:34 <cyns> DG: not sure why having more api is better?
20:53:26 <cyns> DG: want to keep it simple and clear
20:53:55 <cyns> jcraig: it seems less simple to have a bunch of different behaviors and a registry that's a parameter this seemingly simple api
20:53:56 <jamesn> q?
20:54:00 <jamesn> ack jcraig
20:54:00 <jcraig> ack m
20:54:04 <jamesn> ack cyns
20:54:12 <jcraig> q+ Matt_King
20:54:31 <spectranaut_> scribe: spectranaut_
20:55:37 <spectranaut_> 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"
20:55:58 <spectranaut_> DougGeoffray: So you want an api that sends a string, and api that has specialized...
20:56:01 <cyns> ack me
20:56:07 <spectranaut_> cyns: I think I'm trying to say this is not a simple API
20:56:21 <cyns> jcraig: a simple one that just sends a string seems good for basic use case
20:56:57 <jamesn> ack Adam_Page
20:56:57 <cyns> 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
20:57:56 <cyns> 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
20:57:57 <jamesn> q?
20:58:10 <Jamie> q+
20:58:13 <cyns> adam: user intent is different than interupt
20:58:50 <cyns> DG: with screen-reader background, might have profiles for different apps and mapped into verbosity
20:59:30 <cyns> cyns: built into browser so that less popular apps that there aren't scripts for seems better
20:59:33 <cyns> q+
20:59:34 <jamesn> ack Matt_King
20:59:58 <cyns> matt_king: need to workshop these things individually with more time than we have here
21:00:59 <cyns> 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?
21:01:22 <cyns> DG: jcraig, are screen-change events coming from the web page of the system?
21:02:16 <cyns> jcraig: when you change views, there's a UI Accessibility change event notification. Voiceover plays an earcon
21:02:42 <cyns> jcraig: events in this doc are task start, task end, bold start, bold end (menu state change)
21:03:28 <jamesn> q+
21:04:20 <cyns> 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
21:04:52 <cyns> jcraig: api passes strings
21:05:23 <jamesn> ack Jamie
21:05:37 <cyns> matt_king: lets think about whether this should have different methods, and not complicate this for web authros
21:06:09 <cyns> 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
21:07:31 <cyns_> cyns_ has joined #aria
21:07:31 <jamesn> q-
21:08:13 <jamesn> rrsagent, make minutes
21:08:14 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
21:08:24 <cyns_> jamie: this api is about announcing messages. first parameter should never be empty.
21:09:12 <jamesn> s/set the topic: aria live regions/topic: aria live regions/
21:09:16 <jamesn> rrsagent, make minutes
21:09:18 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
21:10:00 <Adam_Page> present+
21:10:01 <cyns_> jcraig: use ID to group announcements from one element, only play the last one, but not suppress all notifications
21:10:03 <jcraig> q?
21:10:40 <cyns_> matt_king: if notification is on container, messages will be on the same element
21:12:43 <jamesn> s/(talking through script)/(talking through script) should keep complete list of roles in this file/
21:13:15 <jcraig> q?
21:13:20 <jcraig> ack cyns_
21:14:27 <sarah_higley> q+
21:14:36 <cyns_> ack me
21:14:36 <jcraig> ack cyns
21:15:39 <cyns_> matt_king: screen-reader should manage this
21:15:56 <jamesn> i/should keep a complete list of roles in this file/scribe:cyns/
21:16:10 <jamesn> i/should keep a complete list of roles in this file/topic: live regions/
21:16:19 <jamesn> rrsagent, make minutes
21:16:20 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
21:16:26 <cyns_> matt_king: only announce when it has focus
21:16:56 <spectranaut_> q?
21:17:12 <jcraig> q+ to say remember this should not be specific to SRs
21:17:42 <Matt_King> ack me
21:18:35 <jamesn> i/cyns: I think I'm trying to say this is not a simple API/scribe: cyns/
21:18:40 <jamesn> rrsagent, make minutes
21:18:41 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
21:18:56 <cyns_> 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
21:19:36 <sarah_higley> ack me
21:20:07 <cyns_> 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
21:20:15 <jamesn> q+
21:20:37 <cyns_> ack jcraig
21:20:38 <Zakim> jcraig, you wanted to say remember this should not be specific to SRs
21:21:39 <cyns_> jcraig: not only for screen-readers - useful for other kinds of AT. Zoomed in, move the banner for the notification into your view
21:21:46 <cyns_> DG: back to the slides
21:21:47 <jamesn> q-
21:21:59 <cyns_> DG: Notification API Array priorities
21:22:23 <jcraig> s/Zoomed in,/Zoomed in with ZoomText or HoverText for example with an out-of-view visual notification,/
21:22:47 <cyns_> DG: insert message at beginning, end of array, clear array
21:23:15 <jamesn> q+ 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?
21:23:37 <cyns_> matt_king: platform API needs to have the richness to manage it
21:23:44 <Jamie> q+
21:24:48 <cyns_> cyns: where does this array live? In the browser? In the platform AAPI?
21:25:00 <cyns_> DG: in the platform AAPI
21:25:26 <cyns_> DG: Notification API - processing recommendations/restrictions slide
21:25:46 <cyns_> DG: Developer feedback to address
21:25:50 <jcraig> q+ to ask about the component scope of notifications, can one part of the page clear the queue from another part?
21:26:25 <cyns_> DG: should you support SSML? SR vendors nervous about that
21:26:46 <cyns_> DG: should it support braille strings? SR vendors - don't block on it
21:27:00 <jcraig> q+ to address the "don't want to hold up the API" comment
21:27:00 <cyns_> DG: SR vendors want better guidance, better docs
21:27:17 <cyns_> q+ to ask about guidelines for AT
21:27:33 <jamesn> zakim, close the queue
21:27:33 <Zakim> ok, jamesn, the speaker queue is closed
21:27:36 <cyns_> DG: Better maginifier interaction
21:27:58 <cyns_> DG: make queues easier to implement
21:28:05 <cyns_> DG: Call to Action
21:28:18 <cyns_> DG: does feedback resonate?
21:28:30 <cyns_> DG: more feedback - what about spam?
21:28:52 <jamesn> ack me
21:28:52 <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
21:28:55 <Zakim> ... doesn't need a message. Is this something different?
21:29:00 <cyns_> q?
21:29:41 <cyns_> jamesn: we hear from developers that they want to be able to announce task succes/failure
21:30:06 <cyns_> DG: guidance - if focus doesn't change, then  announce
21:30:40 <jamesn> ack Jamie
21:31:42 <cyns_> jamie: I have concerns about the array concept, too implementation specific
21:32:04 <cyns_> jamie: horrified by implementation example of custom list box. should just use aria
21:32:11 <jamesn> +1000
21:32:17 <jcraig> ack me
21:32:17 <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"
21:32:20 <Zakim> ... comment
21:32:22 <jamesn> ack jcraig
21:33:14 <cyns_> jcraig: component scope of notifications. Should one component be able to clear notifications from another?
21:33:34 <cyns_> jcraig: let's be sure that we're launching something good, not just fast
21:33:53 <cyns_> DG: Can some features be in stages
21:34:17 <jamesn> ack cyns_
21:34:17 <Zakim> cyns_, you wanted to ask about guidelines for AT
21:34:43 <cyns_> jcraig: as long as it's strucutred so that we can add things in a way that
21:35:12 <cyns_> ack me
21:36:23 <cyns_> matt_king: we are getting feedback in aria-at that guidance is helpful
21:38:06 <cyns_> jamie: it seems that the tone is chaging on that
21:43:17 <dmontalvo-mac> dmontalvo-mac has joined #aria
22:05:49 <Adam_Page> Adam_Page has joined #aria
22:06:20 <andrea_cardona> andrea_cardona has joined #aria
22:07:51 <Adam_Page> scribe: Adam_Page
22:07:56 <dmontalvo-mac> dmontalvo-mac has joined #aria
22:08:12 <Adam_Page> sarah_higley: bit of an overview for folks who have’t followed along or forgotten
22:08:32 <Adam_Page> ... 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
22:08:48 <Adam_Page> ... or a list item, with secondary actions of favorite, share, etc.
22:09:03 <Adam_Page> ... or in MS Teams, a list of meeting participants, each one of which has secondary actions of mute, etc.
22:09:16 <Adam_Page> ... in composite widget roles, there is currently no mechanism to add secondary operations
22:09:32 <Adam_Page> ... you can’t have children interactive items, or non-interactive items in a menu
22:09:38 <Adam_Page> ... there’s no reliable way to semantically create that UI
22:09:52 <scotto> scotto has joined #aria
22:10:02 <Adam_Page> ... there’s a recently merged PR to change the definition of “required owned element” and “required context role”
22:10:17 <Adam_Page> ... define the specifics of what the DOM tree needs to look like for a menu
22:10:25 <Rashmi> Rashmi has joined #aria
22:10:29 <Adam_Page> ... e.g., a menu can’t be nested inside a listbox inside a menu
22:10:46 <Adam_Page> ... there is explicitly no room to add an additional button inside the menu
22:11:01 <Adam_Page> ... i also have a test page
22:12:04 <Adam_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
22:12:04 <Adam_Page> ... there is a lot of discussion for this in issue #1440.  There’s a draft PR #1805
22:12:04 <Adam_Page> https://github.com/w3c/aria/issues/1440
22:12:04 <sirib> sirib has joined #aria
22:12:04 <Adam_Page> https://github.com/w3c/aria/pull/1805
22:12:47 <Adam_Page> ... 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
22:14:06 <Adam_Page> ... for sighted users, secondary actions are often visibly much more discoverable
22:14:26 <Adam_Page> ... in VoiceOver, the actions rotor could be a place for secondary actions to be surfaced, as one example
22:15:18 <Adam_Page> Jamie: Talkback also has an actions menu
22:15:23 <Adam_Page> Matt_King: it’s crazy hard to get to
22:15:30 <Adam_Page> Jamie: 100%
22:15:43 <jamesn> q?
22:16:02 <Adam_Page> sarah_higley: aria-details is another thing that exists and is similar to secondary actions
22:16:14 <Adam_Page> ... has browser and some screen reader support already
22:16:20 <jamesn> i/scribe: Adam_Page/topic: Secondary Actions/
22:16:29 <jamesn> rrsagent, make minutes
22:16:30 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
22:17:30 <Adam_Page> ... the main difference between aria-actions and aria-details — similar in the abstract, but with different concrete UX needs
22:17:43 <Adam_Page> ... so the proposal is `aria-actions="[id list]"`
22:18:02 <Adam_Page> ... may reference any element with a widget role, exclude container roles (e.g. menuitem but not menu)
22:18:25 <Adam_Page> ... 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
22:18:40 <Jamie> q+
22:18:42 <Adam_Page> ... elements referenced by aria-actions do not participate in accname
22:19:00 <Adam_Page> ... elements references by aria-actions are allowed children of their referencing element, or that element’s parents
22:19:29 <Adam_Page> ... two options: 1) all nameable roles (with potential exceptions), 2) all elements of the base markup (with specific exceptions)
22:19:31 <jcraig> q+ to mention frozen element array element.ariaActionsElements
22:19:35 <Adam_Page> ... not `presentation` or `none`, for example
22:19:42 <Adam_Page> ... `generic` is an open question
22:19:44 <jamesn> zakim, open the queue
22:19:44 <Zakim> ok, jamesn, the speaker queue is open
22:19:45 <Matt_King> q+
22:19:51 <jcraig> q+ to mention frozen element array element.ariaActionsElements
22:20:05 <Matt_King> q?
22:20:24 <jamesn> qq+ jcraig
22:20:37 <Adam_Page> 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
22:20:44 <DougGeoffray> DougGeoffray has joined #aria
22:21:01 <Adam_Page> ... author in a tweet for example, becomes an action so you can get to that person
22:21:10 <Adam_Page> ... why not aria-labelledby “yourself”
22:21:23 <Adam_Page> sarah_higley: the idea was name from content should just work
22:21:48 <Adam_Page> ... vast majority of time, I’d expect you wouldn’t want them to participate in accname
22:22:06 <Adam_Page> ... mute button would exist on every person in a meeting, for example
22:22:19 <Adam_Page> Matt_King: could we invert and recommend manual labeling when it’s desirable?
22:22:49 <Adam_Page> Jamie: yeah, understood, we just need to be sure we accommodate aria-labelledby
22:22:55 <jcraig> q? -v
22:23:03 <Adam_Page> sarah_higley: yes, and it will only affect name from content
22:23:03 <jcraig> q? --v
22:23:11 <jcraig> q? v
22:23:24 <Adam_Page> ... the attribute is on the element whose accessible name it affects
22:23:38 <jamesn> ack jcraig
22:23:38 <Zakim> jcraig, you wanted to react to cyns_
22:23:41 <jcraig> ack me
22:23:41 <Zakim> jcraig, you wanted to mention frozen element array element.ariaActionsElements
22:24:04 <scotto> q+
22:24:08 <Adam_Page> jcraig: in theory, this is futureproof for shadow DOM because reflected DOM property would be AriaActionsElements
22:24:22 <Adam_Page> ... so two thumbs up from me
22:24:41 <jamesn> ack Matt_King
22:24:41 <Adam_Page> sarah_higley: yes, should reflect similarly to others
22:24:49 <Adam_Page> Matt_King: this might be controversial
22:24:54 <Adam_Page> ... I’m leery of current scoping
22:25:10 <Adam_Page> ... want to challenge “anything that is nameable”
22:25:36 <Adam_Page> ... 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
22:25:42 <Adam_Page> ... a landmark, for instance
22:25:44 <jamesn> qq+
22:25:55 <Adam_Page> ... does that mean the custom action for that landmark is exposed on every single child?
22:26:02 <Adam_Page> sarah_higley: no
22:26:09 <jamesn> ack me
22:26:09 <Zakim> jamesn, you wanted to react to Matt_King
22:26:41 <Adam_Page> sarah_higley: take a dialog
22:26:49 <Adam_Page> ... a dialog could have a close actions
22:26:55 <Adam_Page> ... there’d still be a visible button
22:27:11 <Adam_Page> ... like an alert dialog, or another dialog that has no interactive items
22:27:27 <Adam_Page> ... so prohibiting aria-actions on dialogs _seems_ like a bad idea?
22:27:43 <Adam_Page> Matt_King: I’m leaning toward prohibiting in that case *would* be a good idea
22:27:47 <jcraig> q+ to explain the "secondary" context and Matt's "prohibition"
22:27:47 <Adam_Page> ... what’s the value to the screen reader user?
22:28:04 <Adam_Page> ... elements that do the actions are things that are present and focusable
22:28:24 <Adam_Page> Jamie: it would be easier to prohibit for now and then add other use cases later
22:28:38 <Adam_Page> ... address the use cases that we care about the most
22:28:52 <Adam_Page> Matt_King: exactly, be conservative here so we don’t have to backtrack
22:29:07 <Adam_Page> ... I have another concern about screen readers that don’t change their virtual cursor focus
22:29:56 <Adam_Page> ... 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?
22:30:08 <Adam_Page> sarah_higley: it’s a tradeoff
22:30:16 <Adam_Page> ... requiring all actions to be present in the DOM is a lot of weight
22:30:31 <Adam_Page> ... especially for a grid, and goes against common interaction patterns
22:31:10 <jamesn> ack scotto
22:31:20 <jcraig> ack me
22:31:20 <Zakim> jcraig, you wanted to explain the "secondary" context and Matt's "prohibition"
22:31:24 <jamesn> q+ scotto
22:31:41 <Adam_Page> jcraig: these are intended as “secondary” actions
22:31:58 <Adam_Page> ... the actions rotor came about in iOS to expose some of these easy access methods that were accessible through some other means
22:32:36 <Adam_Page> ... 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.
22:32:45 <Adam_Page> ... the action rotor has the same intention
22:32:56 <Adam_Page> ... a number of ways to get to the same action
22:33:17 <Adam_Page> ... the intention is to be a convenience; not the *only* way to get to the action
22:34:03 <Adam_Page> ... the bit about “prohibition” where I disagree is I want ARIA primitives that are simple to understand and simple to use
22:34:13 <Adam_Page> ... fewer conditions for the author
22:34:22 <Adam_Page> ... authors are going to make mistakes
22:34:30 <Matt_King> q?
22:34:37 <Matt_King> q+
22:34:39 <Adam_Page> ... we shouldn’t design an API to be overly complicated so that only experts can figure out how to make it work
22:34:54 <Adam_Page> ... the detail on how this action is exposed doesn’t require that a screen reader should be able to land on this container
22:35:30 <Adam_Page> ... let’s say we’re in Gmail, I should be able to easily delete a focused message
22:35:50 <Adam_Page> ... another example is a video container
22:36:03 <Adam_Page> ... play/pause or change audio track is something you can do from anywhere within the container
22:36:19 <Adam_Page> ... I like the idea of a primitive actions menu that works in any scenario
22:36:35 <Jamie> q+
22:36:40 <Adam_Page> ... there’ll always be some web author that comes up with a great example that could break our conditions
22:37:07 <Adam_Page> sarah_higley: I do have a slide for decisions to make which touches on this
22:37:13 <jamesn> ack scotto
22:37:46 <Adam_Page> scotto: you can’t put a button inside a button because the parser will just kick that button out
22:37:52 <Adam_Page> ... there may need to be additional work with HTML
22:37:57 <Adam_Page> ... not necessarily a parser change
22:38:06 <Adam_Page> ... some sort of communication to let them know about a feature like this
22:38:29 <Adam_Page> ... there is a potential feature or guidance that we need to consider bubbling up to the HTML spec
22:38:50 <Adam_Page> ... 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
22:38:58 <jcraig> q+ to suggest this should change element continuations
22:39:47 <Adam_Page> 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
22:39:52 <Adam_Page> ... that’s kind of a button inside a button
22:40:10 <jamesn> ack Matt_King
22:40:43 <Adam_Page> 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
22:40:47 <Adam_Page> ... I look at this the same way
22:41:43 <Adam_Page> ... 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
22:41:48 <jamesn> q+
22:42:06 <Adam_Page> ... and maybe this is the time to suggest that certain screen readers need to change how they behave
22:42:10 <Adam_Page> ... but we’d need to pull them in
22:42:44 <Adam_Page> 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
22:43:00 <jcraig> qv?
22:43:03 <Adam_Page> ... focusing the control could enable access to the secondary actions
22:43:42 <Adam_Page> ... say you navigate to the primary action with your virtual cursor, the SR sees aria-actions, and can then present secondary actions
22:44:04 <jcraig> ack jamie
22:44:07 <jamesn> ack Jamie
22:44:26 <Adam_Page> Jamie: for me the main question is — VO in iOS also doesn’t present landmarks as a navigable stop
22:45:03 <Adam_Page> ... 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
22:46:16 <Adam_Page> ... the fact we can’t spitball a good UX for this is a red flag
22:46:36 <sarah_higley> sarah_higley has joined #aria
22:46:40 <sarah_higley> q?
22:46:42 <sarah_higley> q+
22:47:49 <Adam_Page> Jamie: we should start with a narrow, concrete use case and not be too permissive at first
22:48:33 <Adam_Page> 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
22:48:48 <Adam_Page> Jamie: well, video is an interactive thing
22:49:10 <jamesn> q-
22:49:36 <spectranaut_> q+
22:50:07 <Adam_Page> jamesn: we could limit it to interactive elements only
22:50:23 <jcraig> ack me
22:50:23 <Zakim> jcraig, you wanted to suggest this should change element continuations
22:50:28 <sarah_higley> ack me
22:50:31 <Adam_Page> sarah_higley: we could conceive a third policy option
22:51:22 <Adam_Page> jcraig: certainly this should not allow a literal <button> inside a <button>; aria-actions shouldn’t require a change to the HTML parser
22:51:49 <Adam_Page> sarah_higley: I do want to resolve this so that we can bring it to SR vendors
22:52:02 <Adam_Page> ... and this will come up again later in the slides, so we can pick it up then
22:52:34 <Adam_Page> DougGeoffray: why does a SR user need to be notified that a secondary action exists?
22:53:10 <Adam_Page> jcraig: a sighted user can see these quickly, but a SR user otherwise would need to navigate around to know what’s available
22:53:24 <jamesn> q?
22:53:29 <jamesn> ack spectranaut_
22:53:38 <jamesn> rrsagent, make minutes
22:53:40 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
22:53:57 <Adam_Page> 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
22:54:17 <Adam_Page> ... like in the case of email, if there could be actions on something that’s inside the email versus the email itself
22:54:30 <Adam_Page> Jamie: it also creates a lot of verbosity
22:54:46 <Adam_Page> ... every single node in my email has an action on it, which can be deeply frustrating
22:55:03 <Adam_Page> ... polluting the usefulness of an API.  If everyone is seeing actions all the time, then it starts to become useless
22:55:16 <Adam_Page> sarah_higley: I’ll get through the rest, and then let’s come back to this
22:55:40 <Adam_Page> ... Privacy
22:56:13 <Adam_Page> ... jcraig and I discussed privacy implications at TPAC, but essentially our conclusion is that it does not introduce more risk than we already have
22:56:32 <Adam_Page> ... for the underlying implementation, aaron can talk more about this
22:56:58 <Adam_Page> ... but the proposal is that we can use the aria-details mapping
22:57:28 <Adam_Page> aaronlev: well, wanted to do that initially, but now am thinking it‘s too complicated
22:57:44 <BenBeaudry> q+
22:57:52 <Adam_Page> ... 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
22:58:05 <Adam_Page> sarah_higley: this would be core-AAM and not ARIA
22:58:36 <Adam_Page> Matt_King: I think we’re gonna get good support for this out of the gate
22:58:42 <Adam_Page> Jamie: the mobile web sucks without this
22:58:53 <Adam_Page> jcraig: and we can implement behind a flag
22:59:10 <Adam_Page> sarah_higley: nevermind on the aria-details mapping :-)
22:59:16 <BenBeaudry> ack me
22:59:57 <jcraig> s/ and we can implement behind a flag/ and we can already implement behind a flag without agreeing on all of these disagreements/
23:01:05 <jcraig> s/ agreeing on all of these disagreements/ agreeing on all of the specific details/
23:02:13 <Adam_Page> sarah_higley: another implementation detail is that we have an author SHOULD requirement for aria-keyshortcuts
23:02:29 <Adam_Page> ... or a MUST aria-keyshortcuts _or_ some other keyboard access
23:02:35 <Adam_Page> ... to expose keyboard activation hints
23:03:19 <Adam_Page> ... for tabs in a context like VS Code, tab close buttons are not closeable
23:04:06 <Adam_Page> Jamie: I like this requirement
23:05:11 <Adam_Page> 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)
23:05:52 <Adam_Page> Jamie: so better to have that on the secondary action targets
23:07:15 <Adam_Page> sarah_higley: let me pull up actual proposed wording
23:07:37 <Adam_Page> ... my goal was not to be too prescriptive in how you access the secondary actions, just to ensure that there is keyboard operability
23:08:15 <Adam_Page> Matt_King: does the language say “the target action must be *focusable*?”
23:08:22 <Adam_Page> sarah_higley: no, need to be clickable but not focusable
23:09:10 <Adam_Page> ... either need to 1) be able to navigate to it the DOM, or 2) activate it with keyboard
23:09:59 <andrea_cardona> q+
23:10:04 <Adam_Page> jcraig: re: privacy, the secondary actions must be visible to ensure that AT can’t be detected
23:11:23 <jamesn> q?
23:11:47 <jcraig> s/visible to ensure that AT can’t be detected/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./
23:12:48 <Adam_Page> sarah_higley: aria-actions won’t require that secondary actions are descendants of the referring element
23:14:29 <cyns> cyns has joined #aria
23:14:30 <Adam_Page> jcraig: one example: little hover buttons in Gmail; they need to be visible at the time they’re triggered
23:14:31 <cyns> q?
23:14:58 <Adam_Page> ... alternative example, GitHub inbox: always visible bulk operation for multiple selected items in the inbox
23:15:18 <cyns> q+ 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?
23:15:34 <Adam_Page> Jamie: in that case, we do need to specify
23:15:38 <Adam_Page> ... a practica example: social media
23:15:42 <Adam_Page> ... you’ve got Like, Reply, React
23:15:49 <Adam_Page> ... all these buttons after every single post
23:16:41 <sarah_higley> q+
23:17:50 <sarah_higley> ack me
23:18:57 <jcraig> qv?
23:19:12 <Jamie> q+
23:19:20 <Adam_Page> 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
23:19:22 <jamesn> ack andrea_cardona
23:19:43 <andrea_cardona> ack me
23:19:46 <Adam_Page> andrea_cardona: could you clarify the privacy concerns?
23:20:10 <Adam_Page> 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
23:20:43 <Adam_Page> cyns: disability is sensitive PII
23:20:47 <jamesn> ack cyns
23:20:47 <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
23:20:50 <Zakim> ... AT?
23:21:10 <Adam_Page> 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?
23:21:12 <Adam_Page> sarah_higley: yes
23:21:17 <Adam_Page> ... it should be flexible
23:22:02 <Adam_Page> ... if you wanted to avoid verbose announcement of actions, you could use aria-hidden
23:22:21 <Adam_Page> ... but the *existence* of actions would still be announced
23:23:15 <Adam_Page> cyns: can this be made easier for developers as well as for their customers?
23:23:37 <Adam_Page> ... seems like there’s an opportunity
23:24:03 <jamesn> ack Jamie
23:24:07 <Adam_Page> Jamie: I agree
23:24:16 <Adam_Page> ... I don’t think aria-hidden is the right solution
23:24:29 <Adam_Page> ... if you manage to tab to something that’s aria-hidden, it’s not a good experience
23:24:33 <cyns> q?
23:24:56 <Adam_Page> ... then we’d also need an entirely different way to implement, since aria-hidden is excluded from accessibility tree
23:25:11 <Adam_Page> ... there needs to be a concept of “it’s not hidden, but it needs to be navigable”
23:25:13 <jcraig> q?
23:25:17 <jcraig> q+
23:25:26 <jamesn> zakim, close the queue
23:25:26 <Zakim> ok, jamesn, the speaker queue is closed
23:25:30 <Adam_Page> Matt_King: the solution could be that it must be a descendant of the element?
23:25:45 <Adam_Page> jcraig: could be a SR preference, like “automatically hide descendants”
23:26:33 <jcraig> s/“automatically hide descendants”/“automatically action elements that are also descendants”/
23:26:46 <jcraig> s/ SR preference/ non-default SR preference/
23:27:00 <cyns> q+ to say a user preference and an easy way for authors - both will have preferences based on specifics of the app
23:28:03 <Adam_Page> jcraig: anytime we have an API that hides something as a side effect, authors get it wrong and hide things by accident
23:28:49 <Adam_Page> Matt_King: so what happens in the a11y tree if they are descendants?  How does the reading order get calculated?
23:28:59 <Adam_Page> ... if the SR was going to expose them?
23:29:02 <Adam_Page> ... sounds complicated
23:29:20 <Adam_Page> ... I have a tab that has two buttons inside of it.  Does the SR present those both as descendants of the tab?
23:30:12 <Adam_Page> sarah_higley: yes, and invalid patterns like this are already in the wild
23:30:38 <Adam_Page> Jamie: aria-actions has the potential to make the mobile web in particular a lot better
23:30:56 <Adam_Page> ... and we’ll need a robust way to allow for hiding of actions, to mitigate clutter
23:31:15 <Adam_Page> sarah_higley: I definitely agree that’s an issue, but not sure I buy that it’s directly related to aria-actions
23:31:43 <Adam_Page> 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
23:32:38 <Adam_Page> 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
23:33:44 <Adam_Page> sarah_higley: the thing that worries me is if *authors* decide when to hide things, versus SR vendors
23:35:35 <Adam_Page> cyns: what about a way for authors to hint?
23:37:20 <Adam_Page> sarah_higley: again, that seems related to aria-actions, but not limited to it — should be solved as a separate problem
23:37:57 <Adam_Page> 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
23:38:02 <Adam_Page> jcraig: it does
23:40:35 <Adam_Page> jamesn: what actions are we taking up from this:
23:40:38 <Adam_Page> sarah_higley: things to follow up on:
23:40:52 <Adam_Page> ... 1) nail down supported roles for referring and referenced elements
23:41:08 <Adam_Page> ... 2) confirm whether to use aria-details platform mappings and implementation
23:41:17 <Adam_Page> ... 3) get buy-in on full spec from browser and AT vendors
23:41:23 <Adam_Page> ... 4) Web Platform Tests
23:41:38 <Adam_Page> ... 5) and then this situation we’ve discussed about hiding secondary actions
23:42:07 <Adam_Page> Jamie: can we say that aria-hidden is off the table as a solution for #5?
23:42:35 <Adam_Page> sarah_higley: that was just one example
23:42:54 <Adam_Page> jcraig: it can’t be aria-hidden at the time I activate it, to paraphrase Jamie
23:42:57 <Adam_Page> ... I do agree with that
23:43:36 <Adam_Page> Matt_King: I’m still wondering how that works in the a11y tree, seems like there’s a race condition
23:44:00 <jamesn> rrsagent, make minutes
23:44:01 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
23:44:36 <cyns> q+
23:45:55 <Adam_Page> cyns: is the mechanism for switching between hidden and not hidden too complicated for developers, and can we make it easier?
23:46:02 <Adam_Page> sarah_higley: yes, that’s fair
23:46:19 <jamesn> present+ JamesCraig
23:46:30 <jamesn> present+ JamesTeh
23:46:30 <cyns> or is it good enough for V1
23:46:46 <jamesn> present+ Spectranaut
23:46:57 <jamesn> present+ AndreaCardona
23:47:31 <jamesn> present+ RashmiGarimella
23:47:51 <jamesn> present+ SarahHigley
23:48:12 <jamesn> present+ DanielMontalvo
23:48:22 <jamesn> present+ cyns
23:48:52 <jamesn> rrsagent, make minutes
23:48:54 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html jamesn
23:54:26 <dmontalvo-mac> dmontalvo-mac has joined #aria
23:55:22 <dmontalvo-mac> Rrsagent, draft minutes
23:55:23 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/03-aria-minutes.html dmontalvo-mac