W3C

– DRAFT –
ARIA WG TPAC (day 1)

15 September 2022

Attendees

Present
aaronlev, Adam_Page, bgaraventa, bkardell_, chlane, CurtBellew, cyns, glen_gordon, howard-e, jcraig, Jem, MarkMcCarthy, Matt_King, mbgower, MichaelC, miriam, scotto, valerie_young, zcorpan
Regrets
-
Chair
-
Scribe
Adam_Page, chlane, cyns, jamesn, jcraig, Jem, sarah_h, spectranaut_

Meeting minutes

<Matt_King> Slides for aria-at overview:

<Matt_King> https://docs.google.com/presentation/u/0/d/1KuvI1UIctfMvHJeba0WQGie7JoDNqmOLjiFPNFSEv04/htmlpresent

Seth: ARIA AT is to test interop of AT
… design patterns are source material of what we are testing
… process of writing the tests and the expecte3d output. Then there is infrastructure so we can run it on a large scale
… and for the future figure out how to automate the screen readers
… important not just for us but for the web devs etc. too
… then to share the results and help the community prioritize what bugs to fix
… the project is aria-at.w3.org
… the big goal is so AT users can reliably browse the web
… also a project to help AT and browser vendors find and priotize bugs
… different tests. for Modal dialog closing the modal is a crucial action - one of the tests within the test plan. Then keybaord shortcuts - then the test asks the tester whether the expected output happened
… an example of a test within a test plan. this one had full support in the 3 UA/AT combos tested
… we are writing these tests - have drafted tests for 45 of 65 exmaples. Started with what we think are most impactful
… collecting manual results
… 40 tests per test plan with many more assertions

<jcraig> FYI That dialog escape test should work on iOS too with the VoiceOver "scrub"/"escape" gesture

Seth: manual resutls from 2 or more individual testers and reviewed until there are no conflicts
… published first round at aria-at.w3.org/reports
… meanwhile developing tech to automate
… lots of effort to build drivers for continuous integration
… hoping thst this automation api would have similar support to webdriver
… all of that is where we are today
… bigger vision
… want to expand test suite to cover all aria roles states and props as well as html exmaples
… really want to be automating with manual review
… would allow more data points
… once we have a body of test results that represent an accurate report
… and updated with new AT and browsers
… and would like these to be syndicated using embedded test results in aria practices

should put in spec too
… trying to bring this process earlier in process
… working on implementation of AT automation in NVDA and later multiple ATs
… one of the things we want to talk about today is how can fit into the spec process

Matt_King: key aspect is getting consensus on AT expectations

Matt_King: for specfic attributes

Matt_King: so far in non controversial expectations

Matt_King: much to discuss for things coming

Matt_King: in order to prevent future gaps and conflicts one of the things we are talking about is as part of the spec dev process consider some of the AT expectations

Matt_King: hiatorically havent put normative expectations. If we crafted expectations as part of the process (maybe not normative) then could help with interop in the process

Matt_King: and ensure we actually solve issues for users

Matt_King: quite certain wouldn't have created haspopup as we did

MichaelC: if we are getting harmoniZation then we could explore having normative requirements

mbgower: curveball.... can't have normative language - the power of convention. APG has been powerful in persuading people to adopt patterns

mbgower: visual conventions and programatic specs on role... we don't have to talk about now. aria coming along and clarifying the progrmatic implementaiton. visual cues for the pattern don't always go along with that

mbgower: aria patterns can either converge or diverge those cues. Patterns add customized interactions to the patterns

mbgower: visually things don't always appear the same. voice or other non screen reader ATs

mbgower: what I am interested in is examples which are diverging the allignment on patterns. Would lead to happier situations down the road if they can converge

cyns: mention to a spec - can someone put in IRC

jcraig: I am unclear what the repos do

<jcraig> https://github.com/w3c/aria-at-automation

Seth: ack Jem

<Zakim> Jem, you wanted to addess the junction with ongoing "accessibilty supported" discussion in WCAG and implication to future planning of the project sustainabilty

Jem: in AG talking about whether going to remove a11y supported clause - junction between AG and Aria-At

<s3ththompson> AT Automation API repository: https://github.com/w3c/aria-at-automation

Jem: Shadi tried once for a DB of results

<s3ththompson> AT Automation API latest preview of draft spec: https://pr-preview.s3.amazonaws.com/w3c/aria-at-automation/pull/25.html

Jem: focused on major ATs but Japan for example uses different screeen readers

Matt_King: to be sustainable will need more investment over time. at the moment meta funded

cyns: all AT or just screen readers?

Matt_King: all At over time

<s3ththompson> ARIA-AT Progress Update slides: https://docs.google.com/presentation/d/1KuvI1UIctfMvHJeba0WQGie7JoDNqmOLjiFPNFSEv04/edit#slide=id.gc6fa3c898_0_0

scribe+

ARIA/AAM/AccName Group Processes first session

<spectranaut_> https://docs.google.com/document/d/14dOVzG-nB1P-uLBET3BYC2v_LvfPpUPWvRfqGLUnBzg/edit#heading=h.wfe18rzby46v

valerie: we have two sessions. one is today and the other will be tomorrow.
… we have document to go through but we can start with self introduction.

one question to be answered during introductiuon is what ARIA is doing good and what ARAI is not doing good.

val: I am Valerie - doign well - positive atmosture not doing well/ interdependency to other spect

jamesn: doing well - we are good at listening to different opinion, not good at is that delivering the outcome in a timely manner

jemma: things we are doing well -- I love to work with matt king, we really work hard on having real examples, thoughtful discussion, I like that it takes time

Jem: what we are not doing well, what is "CR"?

Jem: I don't understand the processes

jcraig: I work on apple accessiblity, he/him.

one thing aria group is doing better is mananging the scope creep.

val is doing great as the new chair.

james has been doing great job.

similar to Val's opinion regarding "not doing well' is

tracking the bugs

in a coordinated way

could be the option

aaron: work for Chrome since the first checkbox is implemented.

I rather be careful in delivering spec rather than make them big.

how to manage complex discussion that involves other groups and spec such as css ....

<mbgower> +1 to aaron

will be important

Adma: I m reletivley new to the group.

everyone: welcome

alex: I work for the Boucoup. ARIA is practical and would like to see more architectural limitation.

alex: architectural limitation I meant is ....

@@

chrisl: I am a11y engineer at VMware.

the group is very friedly
… don't have the cristism yet.

markmccarthy: we really work well together in spite that we are the large group.
… challenge may be streamlining the github workflow.
… I work for University of Illinois

simon: work for Bocoup, AT spec proposal
… I like to echo what Alex said.
… accessibility built in process rather that bold on approach will be desirable.

curt: I work for Oracle. he/him

<aaronlev> Death to ARIA — Long Live ARIA!

curt: I appriciate the open discussion

sometime I am lost about the W3C terms and acronyms like Jemma addressed.

sarahH: I work for MS and a developer

co-chairs are fantastic.

similar to JamesN said, more timely follow up on github issues and responses will be great, not necessarily shiping the deliverables quickly

seth: I work for Boucoup. ARIA does great job on big pictures which matters.
… improvment can be done on more crossover effeort both APG and HTML

cyn: work for Google.

doing a good job on opening other groups' suggestion.

we still have lot of issues to solve.
… if we can recruite more member, it will be great.

michael: W3C contact.
… the process - triaging, consensus builing, technically- works very well.
… hard time to draw lines for feature developments

val: aria 1.3 prioritizaiton will be helpful to that point

mck: ARIA is a patienct group - willing to go back and work on the issues

the biggest concerns is growablity of this group - human resource part

more members for wg will be great.

we really need to think about the dept of the group and how to recruit more developers and designer for future work.

bryanG: I work for the Level Accss.
… various spec and the editor for core aam spec

our groups work have impact on the world.

what we can improve is delivering the outcome more timely manner

val: summary - good things: good wg enviroment, great chairs..

https://docs.google.com/document/d/14dOVzG-nB1P-uLBET3BYC2v_LvfPpUPWvRfqGLUnBzg/edit#

things to improve: clarity on the process, working cross with other wgs, and the improvment of work process speed.

CSS Toggle and CSS-AAM

nicole: I'm Chromes PM for Web UI

<TabAtkins> Spec under discussion: https://tabatkins.github.io/css-toggle/

DOM, Fonts, Interaction, Layout... big areas of work

I used to think of Accessibility as a risk for my project

now I think of it as an opportunity

Important benefit for use cases and developer outcomes in addition to users

web devs have too much to do... (examples) can we make it (a11y etc) easier for them

browser should be doing more to ensure a11y w/o needing web devs to become a11y experts

some web devs have mentioned they don't see a benefit to a11y

more conscientious devs are concerns b/c they are unsure whether they have gotten it right

so we (google PM/evangelism) got excited about the ARIA Authoring patterns

so CSS toggle came out of that

Idea that it uses CSS as the primary toggle with accessibility coming along for free

some interactive components are only modifiable in C++ so difficult to extend…

JavaScript custom components are easy for devs to write, but devs don't always consider the a11y

so the goal of CSS toggle is to bridge that gap

thank you for your feedback and participation in this

TabAtkins: intro to the spec

https://tabatkins.github.io/css-toggle/

<TabAtkins> https://gist.github.com/tabatkins/bda9adac50ba7d5616e60ecce9e5cb30

another list of Accessibility interaction patterns, and how toggle could benefit those authoring patterns

google root that sets up a toggle pattern

toggle is visible to the element, siblings, descendants,

any element can respond to or trigger the :toggle

increment, decrement, reset, etc

most commonly toggle between on/off

using this simple pattern, you can implement a wide range of interaction patterns

sop web devs can easily author, and the UA makes it just work

automatically exposed in the most common correct pattern

aaronlev: with the ability to override the UA if needed

should also mention the Accessibility behavior is tied to the keyboard interaction, so the visual toggle, mainstream interaction (keyboard,mouse) and Accessibility are all tied together in this proposal...

TabAtkins: connection between visibility is also apparent to the inference algorithm, so we can make accessible cross refs automatically

<TabAtkins> via the 'toggle-visibility' property

Nicole: there are things that should match the browser... some devs write site-specific or platform conventions, but this would make it easier to match the users' system conventions and improve the consistency of the user's experience

jamesn: confused about some points... what about the checkbox example identifies it as a checkbox?

https://www.irccloud.com/pastebin/dc4wUmeK/

this will be a togglable.... whether it's a checkbox or switch or pressed button?

Nicole: we hope to expand this to other more complex examples

<Jem> o we have conceptual layers to

as we explore what's right for HTML, for Accessibility, etc

<Jem> s/o we have conceptual layers to /do we have the conceptual layer to show the architecture?/

not tied to a particular implementation yet...

scotto: I noticed in the examples that css generated content was used to render a checkbox icon

<Jem> great question, Scott.

I logged some bugs that CSS content will be included in the accessible name... e.g. difficult to localize even with alt text fallback on CSS pseudo elements

cyns: that sounds like a requirement... label inference from the generated content?

Nicole: I'm not sure off this idea would work, but we have considering accessible naming for the states, so the AT could announce or convey that at the time of change or on inspection of the control

<nicole> This is my nic

scotto: these examples use divs. let's say someone used a link for a CSS checkbox toggle, or used it on a div but included a link inside it

there is no content model for CSS, so unexpectedly nested intractables need mitigation details

TabAtkins: yes, if you nest these, we're not sure how to correct that or if it is an error... should be allowed some places,,, maybe not all.

<zcorpan> Spec issue for links in <summary>: https://github.com/whatwg/html/issues/2272

we want to be consistent how we handle this similarly to other poorly nested HTML

Nicole: we plan to add errors in dev tools that help the author: "don't add control X inside control Y" want to increase the visibility of those mistakes

scotto: clarifying... CSS toggle on link,,, both a link and checkbox. which wins out?

TabAtkins: currently it is not allowed to put toggle props on interactive elements

but open question about an interactive inside a toggle

scotto: or making a table a toggle

Adam_Page: does the first example have its role inferred as generic?

TabAtkins: whatever the simplest toggle is. maybe checkbox.

TabAtkins: the names don't matter, but the interaction matters... self activator... strong signal that its a checkbox

<Zakim> jcraig, you wanted to ask about whether it's a checkbox or switch or pressed button?

<nicole> similar example is form elements, they don't need aria roles, but the browser still updates the accessibility tree to be what the role would have said

jcraig: earlier james nurthen mentioned, implied in adams question, whether it is checkbox or switch -- this is simple, we can pick based on the system -- but developers have these choices for a reason. functionally they are all the same, but there is semantic difference conveyed by the visual style. its meaningful information. the screen reader used knows these all work essentially the same way, but the words still tell them more about

the bigger picture.

<Jem> +1 jamesC

jcraig: it's nice we can have overrides, but people might want to

jamesn: if you are overriding the role, how would you override the associated attires... e.g. pressed versus checked

TabAtkins: overriding the role could also handle the APII property diff in the AP

<scotto> i talk too much

nicole: Interaction patterns alsways morph over time. There are patterns that change with web dev trends, does this tab set still act as a tabset or is it a carousel now... Need to figure out.

sarah_h: if someone applies toggle to a focusable, or changes the css class, does it change the interaction or focusability change?

TabAtkins: you can't remove a toggle able via CSS. so can't get into a view dependency loop..

can only remove via JavaScript

TabAtkins: toggles are created as stable state on the element... even a change to the selector later will be ignored.

<Jem> is the toggle like a temporarily mediator?

cyns: documenting what this does should be mapping guide or some other critical resource

bkardell_: difficult to comment on some things without details

what more can you share about the inference algorithm idea

TabAtkins: no more details fleshed out yet... still working on it

<Jem> that is a good rephase of my prior question - inference process, Brain

<Jem> s/brain/bryan/

Nicole: and I'm keeping them on track ;-)

bkardell_: what could change? you said CSS class state changes would be ignored, but could DOM references change?

chrishtr: Nice to meet you all. first time with ARIA

(welcome from all)

why not have a shorthand like "I'm a checkbox" and have the rest be inferred

TabAtkins: the less we force authors to do, the more likely we are to have accessible custom components... but we may end up with the inference nudge

<Jem> at least, this idea might help mobile UI.

instead of saying toggle.. have a CSS property value of checkbox, so the trigger is the role nudge

aaronlev: the developer would use the "checkbox" because they would get all the interaction for free

<Jem> +1 christr

TabAtkins: that's for clarifying... these are split between selectors and properties and many are multiple elements, so can't apply via a single attr

scotto: what considerations have been taken with how this would work with various modalities....

<TabAtkins> TabAtkins: But difficulties don't mean impossible, especially for simple cases like checkbox this might be possible

<Jem> I would also like to preach that the developers need to understand the sementics when they develop whether they have a prior accessibility knowledge or not.

scotto: eg. reader mode. styles would go away.

not saying conflicts would exist, but people do style their controls in certain ways. this may complicate their existing usage

what happens when the user needs a feature this pattern would break?

TabAtkins: partial answer... Reader Mode: I don't believe they ignore all markup...

<Jem> +1 to scott addressing the basic principle of accessibilty, it is not only about the visual.

scotto: e.g. display:none would be ignored in reader mode

TabAtkins: developers of these tools (like Safari reader mode) may have to update to incorporate toggles

<bkardell_> also print*

scotto: seems like reader mode should need to change to respect author style

Adam_Page: how about CSSS specificity?

TabAtkins: that will create a new toggle

jamesn: what about CSS-AAM, cyns?

<Adam_Page> the `toggle` property can be overridden by more specific selectors

cyns: are you documenting the inference algorithm, API output, or both?

cyns: many people will be confused by the algorithm, so it needs to be well documented and clear

cyns: hope a CSS-AAM plan emerges from this

for example, css toggle, css order, when the CSS tree should change the a11y API tree...

sighted keyboard users would also see some layouts as backwards

jamesn: CSS specs say "don't use these layout patterns" if AT order is important, but devs do it anyway

nicole: review spicy sections in Open UI

cyns: nods to bkardell_

jamesn: does anyone in CSS disagree that a CSS Accessibility API Mapping (AAM) guide is needed?

<Jem> The documentation Cyn mentions will be great.

nicole: first step my be the use cases list. start with the highest priority.

jamesn: should this be a breakout document or should each live in relevant part of the CSS spec

jcraig: my vote is to keep as much CSS Accessibility info in the core CSS spec for the featyre

chrishtr: CSS is open to this. for example, some disagreement with flex, but we just need to get to consensus and get the agreement into the spec?

process discussion about how to raise CSS issues for cross ARIA group review

<chrishtr> Being discussed right now in csswg: https://github.com/w3c/csswg-drafts/issues/7387

<aaronlev> Popup API explainer: https://open-ui.org/components/popup.research.explainer

Popup Attributes

aaronlev: how many people have had a chance to take a look?

aaronlev: probably less the half, I'll give a brief intro. Imagine you need to do a notification, there are popups all over the web -- could be dialogs, a chat window, a rich tooltip. Anything you want to show above everything else

aaronlev: sometimes they're activated by hover, sometimes by click, sometimes a notification or toast that is triggered by something in the real world, or page load. They represent a grouping of content that needs to get your attention

aaronlev: you need to be able to navigate to it, maybe see the relationship between that and the trigger. There are three types of popups. It's an attribute and not an element because you may want to put the popup attr on something that's semantic, like a table or a graph

<Jem> for the informational purpose, Sarah also worked/coordinated two tooltip meetings

aaronlev: the popup attr values are manual popup and hint

<Jem> for APG

aaronlev: an auto popup is something you trigger by clicking something like a button, and tabbing out will auto-dismiss

aaronlev: a hint popup is something where you hover over a trigger, like a tooltip or title attr where you can put anything inside that you want

aaronlev: you can kind of mix and match some of the attrs that trigger things, or different popups in different ways

scotto: that's a good high level overview. To touch on the thing you mentioned about it moving over to this from an element

scotto: the thing the various different use cases had in common was people wanted to display content in the top layer of the browser, and wanted dismiss behavior baked in by default. There's a variety of different content types, and all of them were vaild, but none fit into a single element. It made it difficult to specify what the underlying role should be

<aaronlev> Accessibility proposals for popup:

<aaronlev> https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit#heading=h.7fodzd7pkxs0

scotto: this conversation is about what to do in some of these situations, how to make sure that important properites for accessibility like the relationship between a trigger and its popup are exposed. To make sure that what developers can and will do, e.g. the popup blog post that went out, a lot of these popups could be on divs. This is a global element, similar to contenteditable or tabindex

scotto: what do we do in these situations? There are some legitimate use cases to put this on a generic, and there are some cases that will be problematic.

aaronlev: similar to the CSS toggle discussion, we have to think of this as using heuristics, since there are a lot of things you can do with the markup. The popup attr describes behavior, not semantics

aaronlev: I'll give an exmaple: a hint popup could be used to put a simple piece of text, like a title attribute. It could also be used to create a rich dialog

aaronlev: one of the ideas we have is something called rich hint and plain hint. We'd determine the behavior based on the content within the hint itself. If it's a rich hint, it's interactive and has features a user needs to reach and navigate to and explore, including tabular interactive. It might not be interactive. The triggering element must be in the tab order, and they must be able to tab into the hint itself

aaronlev: if it's a plain hint, it only needs aria-describedby. If we put every title and plain hint into the tab order, the web tab order would be even more cluttered than now. I think it's a good optimization of the a11y experience to make that determination

aaronlev: another area we're looking at is the idea of a minimum role. Because things can be on divs, popup content can bleed into the page without a boundary. If you have a popup=manual or auto, you would have a div with at least a role of group, meaning it would get an auto role of group to help the user differentiate between it and ther est of the page

aaronlev: and a hint popup would get a minimum role of tooltip.

<jcraig> so <div popup> would be mapped to group in HTML-AAM?

<jcraig> seems reasonable

aaronlev: the other areas are the keyboard nav model for all 3 types, and the a11y model for all 3 types. I've marked all areas we need feedback on, TBD. We want feedback on everything

aaronlev: there's also reading order: it's possible to associate the popup with the trigger, and the DOM content of the popup could be anywhere, not necessarily after the triggering element

aaronlev: our suggestion is the tab order needs to reflect what the user sees, so it should go into the popup, regardless of where it is in the DOM. And aria-details can be used if the popup is not next to the trigger in the DOM

cyns: anyone know how well aria-details is supported?

aaronlev: aria-details is still getting budding support. It's about 25% of the way we need to be. It's supported in ChromeVox, and some basic support in JAWS and NVDA

<jcraig> aria-details supported in WebKit/VO. WebKit diff at https://bugs.webkit.org/show_bug.cgi?format=multiple&id=165842

Matt_King: I'm hoping we get to talk about how we will go about gathering feedback and making decisions because this reminds me of our convo earlier this morning. One of the things I think we don't do well as a working group is user research and understanding whether we are solving the problems of users or even creating more problems. I'm really concerned about some of the implications of the proposal because they will bake interaction into brows[CUT]

Matt_King: term in the same way some people find frustrating today -- legacy decisions, for example the fact that you can activate a button with a spacebar, but when you hit space on a link, it scrolls the page

Matt_King: it just confuses the heck out of people

Matt_King: this proposal I'm especially thinking about all the tab key stuff related to hints and the reliance on aria-details, and the fact that we haven't really defined AT expectations for aria-details and how they can support details in ways users will understand

<jcraig> short link of above https://webkit.org/b/165842

Matt_King: I'm just hoping we'll talk about the process of how we go about this. The other thing I'm hoping is maybe we could carve this up into things we know, go forward in little bits at a time rather than all at once

Matt_King: try to scope it in ways where we're making sure we're not introducing complex controversial or new long-term problems

aaronlev: I'll let Nicole talk about the user research part of it

aaronlev: we have a doc I think I've shared that defines AT responsibilities with aria-details, because we don't specify AT behaviors, so instead I wrote a doc and shared it with AT developers, browser, devs, stakeholders

aaronlev: I didn't initiate user research with all the AT users, I think that would be an amazing thing. I think going backwards in the web with even a static page and how hard screen readers are to use with it would've been good

aaronlev: I also want to address the collaboration bit, this is all rough, we're trying to be logical at this stage. We're creating prototypes, popup is still not out there on the web, so this is our chance to change everything

nicole: I can speak to the UXR part, This is the the part that worries me, especially as we're trying to bring a11y to users without more effort from devs. We want to make sure that what we're shipping is better than what we have now

nicole: I think the only way we know that is to test with users of AT. It wasn't clear that some of the patterns we're working on haven't been tested thoroughly. We want to do tests around different kinds of toggle and how meaningful that is to users, but I think there are tests we can do with popup too

Matt_King: I don't think it's just missing research, I'm thinking of the process of doing the research, for there to be discussion of the research design and goals that's open and thoughtful

Matt_King: I think in a lot of solutions we have a chicken and egg problem where take tooltips, as far as I'm concerned as a SR users, tooltips are just a SR nightmare, and there isn't a usable solution with any screen reader. Nobody's imagined a way to make the experience of tooltips as effective for screen reader users as it is for anyone else

Matt_King: ok, maybe no one likes tooltips :D

cyns: there's a user researcher on my team who has experience doing studies with users with disabilities who might have time

<Jem> I liked the discussion of potential dom order.

cyns: that's a great way to affect designs

scotto: I just wanted to add, one of the things about popup being an attribute and the fact it is three different behaviors. This makes things some devs are doing now a lot easier. I know one thing popups solves is it allows content authors are currently shoving to the end of the DOM for z-indexing and layer issues -- this allows those popups to be next to things in the DOM. That's something devs currently can't do right now. If used in this way,[CUT]

<Zakim> Jem, you wanted to ask to learn how to deal with the third use case of complex/interactive contents inside the dialog - like interactive grid, (ex: embeded tableau data) which may not be covered by aria-details. or will it be covered by aria-details?

scotto: problem that exists. But also, now authors can put things anywhere in the DOM. We now want to push the conversation in how to mitigate for less than ideal solutions now that there's a way to do this easier

Jem: I was just thinking about the third case, I see that in the university we use a popup, and they embed lots of tableau data inside popup. I think this is another example in addition to simple and rich text data that can be covered by aria-details. What about this third case with very rich data, grids, etc. inside of popups?

aaronlev: like an interactive grid?

Jem: yes

aaronlev: that should be OK, any kind of rich interactive content should work. THe user just needs to discover it, interact with it, using their screen reading commands. They also need to not fall out of it by accident, but other than that

chrishtr: I wanted to respond to some of the comments about tooltip. I think you mentioned no one has come up with a reasonable way for SR users to use tooltips. It sounds like in practice it'd be better to have them filtered out, is that fair?

Matt_King: not necessarily

aaronlev: they are exposed in a way users can filter them out

chrishtr: they may not be, depending on how they're implemented

aaronlev: with the hint proposal, they'd be exposed in the same way as the title attr

chrishtr: so because the hint popup exposes the fact that it's a hint-based popup thingy, it probably makes it easier for a user to filter it out

Matt_King: I'm more concerned about the interactivity baked into this

aaronlev: with regard to usability testing, I think that'd be awesome. I'd have to talk to cynthia or others. WRT aria-details not being mature, there is another option, which would be to mutate the a11y tree to put the popup content next to the anchor. I wanted to avoid that because of how difficult it is to implement aria-owns in a stable consistent way

aaronlev: we're thinking we want to support a minimum role on popups. We want to implement aria-expanded where it makes sense. We may want to find something better than role=group to show to AT so users know they're escaping something. You don't want to accidentally let people leave or navigate somewhere else unintentionally

jcraig: role or something else?

aaronlev: I think an attribute

<Jem> yes. I also heard a lot of complaints that people get lost a lot with pop up.

aaronlev: think something like aria-island, without getting hung up on the name. It'd be something that ATs would need to support, that would warn you when you leave, and you would have to verify the action somehow

aaronlev: we have to talk about initial focus, F6 with async popups, what happens on page load

<jcraig> aaronlev: bikeshed aria-island

<jcraig> got it. a interaction primitive similar to modal

aaronlev: then there's keyboard nav, when does initial focus go into a popup. Is it when you explicitly opened it with the keyboard, or as long as the popup is not an async popup or on page load?

aaronlev: Let me go through some of the TBDs here

aaronlev: we have to consider implications for touch. Like you said tooltips are not ideal for SR users, they are also not ideal for keyboard or touch users currently. Finally we have to decide whether rich hint popups cause their triggers to be in the tab order so users can activate them

<Matt_King> fq+

Matt_King: I think one of the areas of biggest research I'm concerned about is related to focus and keyboard, in particular this area of light dismiss. I'm really concerned about tab principals for how it should work. I think one really important one that I find nightmarish when it's not followed is that shift-tab will undo what tab did. If you tab forward and backward, you shouldn't be going to a different place.

Matt_King: if you were in a popup and tabbing out dismissed it, tabbing backward won't get you into the same place. That feels like a true nightmare to me. I already experience this a lot. It's something for us to really think hard about.

aaronlev: It's a good point. As a sighted users, I can see visually when I'm at the end of it. It's not as obvious when you're at the end as an SR user, and the tab might close it. We should consider cyclical tabs

Matt_King: it's something to consider. But if you can't tab out, should you be able to tab into something.

scotto: I want to respond -- some of this behavior, like the ability to tab away from a popup. Think about a listbox that comes from a combobox -- tabbing away is expected behavior. i think it's important to not be too prescriptive because popup as an attribute needs different behaviors based on the underlying element it's applied to

scotto: everything you're saying Matt I absolutely agree with, but some of the behavior you're describing, I'd expect people to be using a dialog. I think we need to figure out what to do when someone is using this on a div with no other semantics. I think popup won't solve all these problems b/c there isn't only one solution

scotto: clashes with aria owns

sarah_h: I just want to register agreement w/ aaron that I don't think browsers should auto-move popups next to the button without authors having some way to undo it

can't reuse that code

aaronlev: yeah, I've spent a year fixing bugs with aria-owns

aaronlev: this seemed like a place to increase the value of aria-details, because we're going to need that

<Jem> I am thinking that 'light dismiss" may violate WCAG in regards to conginitive disability although I cannot think of specific SC right now.

aaronlev: I moved this back to a google doc from the github discussion because otherwise it was unreadable. If anyone has issues reading it, I'm happy to move it back to a wiki. I found it a good way to collect feedback and improve the actual text

aaronlev: are there any objections to doing it this way for now?

Matt_King: the current explainer, is that on a wiki now?

aaronlev: I'm talking about the google doc I emailed earlier today to the public aria WG

<Jem> what is this then, https://open-ui.org/components/popup.research.explainer?

<aaronlev> https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit#

aaronlev: I've written a popup a11y proposal

jamesn: can you put a link in IRC?

<Jem> Thanks for the google doc, @aaron

aaronlev: it has the collected wisdom we have on the a11y concerns. It links to the explainer and says given that, what's the best we can do for a11y

Matt_King: can we add a link to the google doc from the explainer?

scotto: I don't see why that would be a problem

How to handle unlabeled elements

How to handle unlabelled elements

https://github.com/w3c/accname/issues/138

jcraig: We can agree on some changes then discuss

user jumped into articles with article rotor

see a heading that would useful

makes sense

dissallowed to pass up in browser

CSS prevented

intial issue was heuristics will get better

is an auth error

ARIA wanted something rigid

name from heading is a good idea

everone agrees

ML heuristics should be better

<jcraig> Original Issue https://github.com/w3c/accname/issues/138

#138 in accname

<Github> https://github.com/w3c/aria/issues/138 : HTML-AAM: audio UIA should have localized control type

rragent, make minutes

aria issue #899

<Github> https://github.com/w3c/accname/issues/138 : ARIA Spec could be more flexible when elements with "nameFrom:author" are left unlabeled by the author

<jcraig> Old PR from Jon https://github.com/w3c/aria/pull/1018/files

repo accname 138

aria 1018

feedback on #1018

<Github> https://github.com/w3c/aria/pull/1018 : Issue899 accname from heading

aaron will take over

couple of things need agreement

most cruft and whitespace diffs

no nesting with landmark roles

think it is unecessary

any objections?

<Jem> "heading: name comes from the text value of the first descendant (i.e. depth first) element node with the role of heading, with landmark roles heading elements used for naming are restricted to first child node."

Matt_King: role=region object doing this at all

ok for other

<Jem> https://raw.githack.com/w3c/aria/issue899-accname-from-heading/index.html#namecalculation

jamesn: why label complimentary?

or nav

if there is a label we can read that

Matt_King: useless to hear complimentary

jamesn: risk 1st heading could be halfway down

aaron, heuristics better than first child

come back to that

remove 'A heading can only be used to name its nearest ancestor element that follows from heading"

overcomplicates implementation causes slowdown

simplifying John's PR

Matt_King: what are the side effects?

if its a sloppy page or incomplete implementation

2 nested containers could share a label

<Jamie> A bit late here, but it's worth noting that the first child restriction on landmarks would solve the risk of the heading being half way down the landmark.

redundant for user in worst case

sarah_h: content region 1st article has a heading,

like and landmark region

jamesn: 6 roles to get name from heading

alertdialog,article, dialog,complimentary,navigation,region

aaron changing what name from heading means

aaron DPUB roles they want

jamesn: if you have a heading no need to provide a name

Matt_King: don't go down that path

<Jem> Now I understand what two James meant "simplify"

concensuss for removing

'A heading can only be used to name its nearest ancestor element that follows from heading"

Matt_King: if you are using region you should know name is required

author should be listed before heading

big removal

<jcraig> Jon's proposal: "Authors MUST give each element with role dialog a brief label that describes the purpose of the content in the dialog. Authors SHOULD use the first visible element with role <rref>heading</rref> of the dialog to provide a label whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role <rref>heading</rref>. If a visible label is present, but not

<jcraig> contained in the first element with a role of heading, authors SHOULD reference the visible label with <pref>aria-labelledby</pref>"

<jcraig> My counter proposal: Authors SHOULD give each element with role dialog a brief label that describes the purpose of the content in the dialog.

aaron, this is for the authoring spec

Matt_King: if this is error correction we don't need this

why would'nt we allow authors to label with a child header

authors will accidentally get it right

<Jamie> If it's not error correction, then the possibility of a heading halfway down a landmark is pretty worrying.

Matt_King: what the specific requirements should be

what qualifies as label from child heading

dialog > p > heading a label will be needed

jamesn: entire <p> is meaningless

a "duh" requirement

concencus to remove?

yes

Matt_King: confused if we are going in 2 directions

line 6552

jamesn: sections aren't landmarks unless they are labelled otherwise you have unintended landmarks

non proliferation

Matt_King: dialogs

Matt_King: this isn't error correction

this becomes a name technique

Matt_King: concerned about the ability to detect articles/dialogs that are missing labels

if the heading is not a good label

and we just pulled out the structural requirements

with no author MUST related to structure

you can't to check to see if is is labelled

aaron,you can check

Matt_King: not for an intentional label

jamesn: technically valid

same tool cannot check for correct img alt text

Matt_King: at least the author tried to specifiy alt text

in this case the author did nothing

aaron

golive required alt text

and authors used "."

Matt_King: we don't have a problem of "." for a dialog heading

the heading may not be a good label

no author MUST

is a problem

aaron aknowledged

authors won't use checking tools

Matt_King: we build them

Matt_King: we could make our own internal rules but not a good idea

jcraig: the reason this exists is the 99% is the best guess

Matt_King: satisfying name is requiered is what I'm talking about it

jcraig: user over authors

still say the change is worthwhile

sarah_h: scott tested role=region exposing nameless regions

don't think 1st heading is the right solution but it might be worth reconsidering

scott comment 8/1/2019 on the PR

Matt_King: going back

no longer agrees with concensus

agree with error correction

jamesn: authors must ensure the first header must be a meaningful name

naive checkers won't know what is meaningful

jamesn: article 1 article 2 is worse than first heading

jcraig: not going to commit this

just clean up this diff

Matt_King: there could be middle ground if we can get a preview working

jcraig: back to original proposal

error scenario, name from heading solve these cases

the reason I put this there

ML techniques are changing how AT accross the board

aknowledge in spec

to let browsers provide the best thing to the user

jamesn: can you provide the language that prevents this?

jamesn: AT corrects things, why is this different?

webkit or VO has to cheat

jamesn: can solve without spec changes

expose as guessname

Matt_King: it should still have no name in the a11y tree

<Jamie_> That also allows AT to differentiate a guess from reality, which could be useful to tell the user that it might be problematic.

text separation

jamesn: PR is old and hasn't been merged, which makes me think it's not the right approach. I want to talk about what we were trying to solve

jamesn: I think we were trying to solve the issue where you have various text nodes that are either spoken together when they shouldn't be or they are separated out by AT when they shoudl be a single example. for example formatting inside a word

https://github.com/w3c/aria/pull/996

jcraig: more history: div and span should use generic role they are the same presenation-wise. based on span being inline and div block, api stuff exxposed differently, and AT knows not to jam them together

jcraig: some ppl didn't think span and role should be the same, so we did text separation

jamesn: now that we have generic, what problem is text separation trying to solve that a real world developer has?

jamesn: solves teh same thing as text=static (sp?) changing how strings are read

jamesn: propose that we don't do aria text separation and bring back a form of role text status

matt: the problem is that a role change changes the role, but a property allows ...

jamesn: role=text is a specialized version of role=generic

jamesn: apple has role=text implemented in webkit. Have their been problems with it?

jcraig: we had role=text before it was proposed. there was a large set of contnent that relies on it not changing. Joanie had reasons why role=text is not the best. role=static would address that and Apple's backwards compat

jcraig: problem is with an implementation or role=text that makes children presentational. Changing behavior of role=text problem

matt: back to the problem

jamesn: where does text separation go? overly complex for the problem it's trying to solve

jcraig: problems with implementation with os accessibility apis having to look at sibilings

cyns: sounds like performance problem

jamesn: Only textual contents allowed (author error)

matt: role generic didn't solve the div and span problem. If you want to separate content that's in spans, you have to add additional space characters. Or if you want divs to be treated like spans (no pause) you have to change them to spans

matt: That is still the problem that we're trying to solve

matt: need to look at list of practical use cases

cyns: I was in a meeting about pronounciation guidelines and it seems there is a lot of overlap, which I think is interesting -- pausing/adding pauses...

jamesn: maybe not, because that discussion was adding pauses on purposes

jamesn: where this is just a word getting put in different blocks unrelated to the author content

ok

matt: when you have a kbb element inside a sentence, you're reading the sentence and then it stops

jcraig: read from here can pass that

jcraig: kbb is there for a reason, which is why there's a pause to let the user know

<Zakim> jamesn, you wanted to suggest a path forward

matt: one example of a use case

<jcraig> discussion was about multiple interaction patterns for navigating inline content that is styled differently for a reason. like <kbd>

jamesn: we should close the text separation issue, it's not useful or implentable. Anyone disagree

jamesn: open a new issue with the fundamental use cases we're trying to solve

<jcraig> I mentioned to Matt_King that VO+A (Ctrl+Opt+a or CapLock+a) continues reading a the end of each inline element

jamesn: create a draft PR for role=static

matt: didn't go to children

jamesn: could have test tools and maybe UA not expose if there are the wrong children

matt: we can look at the pr proposal

matt: one problem I remember was that it blocked access to content. Let's look at failure use cases where role=static blocked child content

matt: example I (heart emoji) NY got read as I love New York, no way to know that there was a heart emoji

jamesn: maybe we can find a way to resolve objections, or maybe not and it's still worth moving forward

matt: yes, but look out for side effects

jamesc: Jamie, last night we talked about Scotts PR suppressing role description. That is what it's doing. The primary benefit is simplifying implemntiona

jamie: commented on PR, it's ok

What to do with name prohibited?

jamesn: in 1.2 we introduced a new category of roles, name prohibited

jamesn: for things that could not be names, like generic and paragraph, things that generally only contain text or are generic containers

jamesn: in 1.2 it wasn't a problem, it was only author requirements

jamesn: but in 1.3, for some reason I don't know, we prohibited user agents from exposing the name of something that is prohibited

Matt_King: the reason why is that we decided to add it in 1.3 when we were discussing it in 1.2. it was a timing issue with going into CR. we delayed the user agent requirements to 1.3

jamesn: but why?

Matt_King: I remember being a proponent of the user agent requirement because it the user agent surfaces as a name for an element where the name is prohibited then authors are not aware of the fact that they are creating a problem

jamesn: so we went down that path, but we got a lot of feedback, like the ones linked in the agenda

jamesn: some of the issues are when a generic or prohibited becomes focusable

jamesn: seems like name could be a good fallback in this scenario

jamesn: I believe the user agent implementors were reluctant to implement

aaron: I have a document that I wrote, I'm trying to find, the problem is inconsistent screen reader behavior. We haven;t found a good way around that. if you remove the name the expectation is that it breaks webpages

aaron: a lot of authors only know about aria-label and its a bandaid and they are trying to annotate

<jcraig> https://github.com/w3c/aria/issues/1487

aaron: it happens often enough I think we should allow it

aaron: now that we don't prohibit it, we have inconsistent screen reader behavior

jamesn: chrome started to implemented "do not expose name when prohibited" then it encountered problems, so they didn't implement

jamesn: so we don't have implementations of the 1.3 specification, unless implementors agree to implement, we have to remove it

<jcraig> https://github.com/w3c/aria/issues/1476

<jcraig> https://docs.google.com/document/d/1mcce70oxAl03_P6uzWldZ2nhGHoteaMlpVl5KWszFdk/edit?usp=sharing&resourcekey=0-zjDvv9ENpmNvJeX4TFTfsg

jamesn: all three linked bugs are essentially the same issue

<aaronlev> https://docs.google.com/document/d/16AysDIyGt7IfazLmLP8wFsnTTBFKWPDBA50z9LDm6tA/edit#

aaronlev: I had some discussions with jamie about the problem and this is the result ^

aaronlev: proposal, keep exposing it as an accessible name, and trying to convince ATs to expose

aaronlev: next proposal, ....?

aaronlev: next proposal, expose the name as "aria-description"

aaronlev: next proposal, if on a generic element, then do a repair and have a minimum role of group

Matt_King: I feel like all of those....

Matt_King: I don't understand second proposal

aaronlev: second proposal... I can't quite remember, jamie do you remember you have a blog post

Matt_King: lets go to the beginning! we put name prohibited on certain roles for a reason, we don't want authors to name these things

Matt_King: we shouldn't change things so that authors can name them

jamesn: validators flag it as an error!

Matt_King: what do you mean keep on doing what we are doing?

aaronlev: we should be strict about what we require and loose in what we prohibit

aaronlev: and instead try to repair

jamesn: how are we going to move forward to get 1.3 out?

jamesn: we need to remove the user agents must not

jamesn: user agents need to do something for error correction purposes

Matt_King: can we say "may not" instead of "must not" because then they don't need to expose as an accessible name

jamesn: I'd like to remove the statement, add an authors notes about the discussion continuing, but we can't publish this in 1.3 because there are not plans

jamesn: that ok?

james: we won't forget about the issue and make it clear to readers of the spec that the discussion is on going

jamesn: also I'd like to have more editors notes to describe things that are in flux

Jamie: I would object to the statement remaining in the spec

jamesn: we almost got agreement to remove the statement in a previous meeting, I just wanted to confirm it with more people

no objections

jamesn: so lets discussion options for the long term solution?

jamesn: back to aaron's document

jamesn: three options

Matt_King: I think 1 and 4 are problematic

Matt_King: I think 3 is ok, with "name-from:prohibited-name"

Matt_King: one pro that is not listed is that the aria label will not be treated by name calculation as a name

Matt_King: so in the accessibility inspector will not show a name

aaronlev: it will show in the description, and under the reason it will say where we got it from

Matt_King: I like that because it is explicit

Matt_King: if that results in duplicative speech, that is an good result, because you did something you were not suppose to do

jamesn: if we are only talking about dev tools -- you could expose in the dev tools more clearly that this is a fallback and an error

Jamie: it is not a given that an AT will read a description

Jamie: it is not defined that a AT will handle a name in a particular way in the name prohibited case

Matt_King: if the browser exposes a name that is prohibited, it is more likely that the AT is going to treat it as a name

Jamie: it's tricky. if it is what the author misguidedly intented.... it seems like it is also misleading to expose as a description

Matt_King: but we do that already with a whole bunch of stuff

Matt_King: some times a name is a name sometimes it is a description. I think we are talking more about authors than users

jamesn: this is like a guess. we should expose it as something different and AT can do what they want

Jamie: this is error correction, always carries some risk and is hard

jamesn: this is "an invalid name" should be exposed

aaronlev: if we move to aria description, ats are working on trying to do this consistently,

jamesn: so we should use description instead of making a new idea because that will take forever to get AT support

Matt_King: I think this is the best for users and lease confusing for authors

Jamie: as much as I expose to role="text" people use it because they want that behavoir

Jamie: an empty generic might not expose a description or a name to an AT -- the solution it solves a few use cases, there is still other issues we aren't discussing

Matt_King: it is not our job to solve author errors. we want to prevent author errors and occasionally, when it is clear benefit to users, allow user agents to correct something

Matt_King: we don't want to fix every anti-pattern

jamesn: we don't want to prevent at and browsers repairing things

Jamie: do you have anecdotal evidence that empty divs and spans with aria labels are more or less common than divs and spans with content

aaronlev: I'm pretty sure most of them are not empty

aaronlev: I wouldn't have thought of that so thanks for bringing it up. but with that in mind I think it is a still acceptable solution

jamie: I think we are overloading annotations

jamesn: thanks everyone!

dialogs

<bkardell_> can I just ask "would you like me to get an answer to the previous question from the http archive dataset?"

Matt_King: there was homework for this
… kind of long, so here’s some help
… there is an issue in ARIA #1708 referring to non-modal / modeless dialogs being treated by screen readers

<Github> https://github.com/w3c/aria/pull/708 : IDL attribute reflection branch

Matt_King: there was a proposal that they be recognized as landmark in regions
… in #1708

<Github> https://github.com/w3c/aria/issues/1708 : tracking issue for <dialog> & role=dialog

Matt_King: I did not support, and wrote a counter proposal

<Github> https://github.com/w3c/aria/pull/708 : IDL attribute reflection branch

<Github> https://github.com/w3c/aria/issues/1708 : tracking issue for <dialog> & role=dialog

Matt_King: the net of this is that we need a different kind of container available to authors
… very different from landmark regions, in order to solve pressing problems
… things we can do in native software, but not on the web today
… essentially create an application with multiple windows
… where each window is a non-modal dialog
… in this proposal, I made up some new terminology
… to describe how screen readers present different containers
… kind of screen reader CSS if you will
… solid, porous, and hidden
… read doc to understand
… the one that matters for now is that screen readers treat modals as if they have solid boundaries
… so in normal navigation, next item, list all headings, etc., when you’re in a modal or specific window, you’ll only see content in that container
… on web page with many landmark regions, you’ll see all on the page
… and can easily navigate to next item across region boundaries
… but non-modal dialogs are not the same
… the proposal is to have screen readers treat non-modals the same ways modals
… and have the same expectation for non-modals on the web that we have for inter-app windows, modeless windows, etc. within native application
… or the OS/browser presents a way to navigate between currently open non-modal windows
… an opportunity to solve real challenging usability problems on the web
… currently no way to do this
… e.g., comments sidebar in Google Docs
… imagine a gaming app with chat side-by-side; don’t want things mixed in, confusing the user while they’re trying to play game
… what should this mean in terms of spec language?
… some specific ideas for things to be done by screen readers and browsers
… there’s a WHATWG issue related to deprecating dialog.show
… would not want to deprecate if we pursue this
… so definitely consequences in HTML, unsure of what it would mean for ARIA spec
… dialog is a child of window and doesn’t matter whether it’s modal or non-modal

Jamie: thanks for summary
… couple clarifying questions:
… we’re talking about HTML element and role both
… F6 is somewhat browser-centric, implemented by engine
… could be overridden by JS, but should you?
… are keyboard shortcuts _spec’d_ in ARIA?

Matt_King: normative: authors are expected to manage focus, but not specific shortcuts

Jamie: how we do keyboard stuff for dialog might need to be different because of F6
… flagging keyboard-specific spec risks
… a lot of behavior is at AT level

Matt_King: I don’t know if we would want to add specific language to dialog role description
… to put expectations on AT
… to depend on modality

Jamie: the spec can’t currently require an AT, so it would be a recommendation
… in general, more unbounded regions don’t seem like a good thing
… we have enough unbounded things as it is, users can get lost
… devil’s advocate: your proposal assumes users find desktop apps _easier_ to navigate. Not necessarily true
… in Narrator, having Scan access in any app gives advanced users freedom
… less advanced users are not aware
… touch screen screen readers may be less efficient, but flicking left & right is easy

Matt_King: that assumption is true for some users *but* native solution does not address problems of solid boundaries for all users
… and we can do a better job on the web
… I have a “goooooooooooogle” of ideas
… can better support users if a screen reader offered “insert R” to change restriction level
… no good reason not to allow easy changing of restriction

Jamie: NVDA for example treats all dialog boundaries as solid

Matt_King: you’re already doing this?!

Jamie: does anyone disagree with assertion that dialogs shouldn’t be landmarks>

jamesn: easiest to get things done. If we don’t have appetite for it, then landmark is easy pragmatic solution

Matt_King: based on what Jamie said and what I know about JAWS, but we already have dialogs treated as elements with solid boundaries by VO, JAWS, and NVDA
… so whether it’s modal or non-modal, it’s easy — asking screen reader to keep doing what they’re doing for modals for non-modals

jamesn: if they shouldn’t be a landmark, what should they be?

Jamie: a little controversy here
… ATs have to treat it as a landmark because of the spec
… putting it in spec as landmark sets up restriction that we cannot move past

jamesn: seems fair

o

aaronlev: what are we putting in as replacement?

Jamie: dialogs are dialogs

aaronlev: if there were 2 or 3 modeless dialogs on page...?

Jamie: depends on whether you want to go into F6 territory

aaronlev: ARIA doesn’t drive keyboard behavior

Jamie: if I were making this decision for NVDA, I would include dialogs in the landmark nav command
… BUT
… they wouldn’t expand their content into the document, which landmarks _do_
… they would not have porous bounce (?)
… when it’s in the spec as a landmark it has to be treated with a porous boundary

Matt_King: that raises interesting questions
… is the web mature enough now that we can actually talk about another mechanism besides tabindex
… that would allow a behavior like F6, like “window ring” or some command
… what would the mechanism be for adding something to the HTML/browser

cyns: tabindex is in HTML spec

Matt_King: if window ring also included landmarks, then each window could cause a whole bunch of landmarks

Jamie: huge can of worms

Matt_King: in game+chat, you just want to F6 back and forth really quick

cyns: there would be Tab and F6 and some other key for landmarks

jamesn: let’s not discuss mechanisms, there could be more than keyboard

jamesn: how can we get browsers to implement these things?

cyns: landmark nav and something like F6
… don’t know how hard it is to implement. There’s UI in addition to web platform

aaronlev: it’s more philospohical purity
… when we first did ARIA, we did it in one browser
… just with windowize, if you use ARIA and you use tabindex, it’ll be keyboard navigable in IE and screen reader accessible with Firefox and JAWS
… ARIA does not affect how things are clicked on; tabindex came from HTML
… ARIA is always an override for semantics
… HTML in ARIA changed that
… nice to be able to say “ARIA does not implement your widget for you”
… philsophical purity is not always what’s best for user

aaronlev: they are adding focus group to HTML

cyns: maybe this feature belongs in HTML and not ARIA

aaronlev: but then some people will put that on their landmark and some won’t

Matt_King: some authors will and some won’t. Important design decision

Jamie: this is not a new problem

jamesn: if people have too many landmarks, better to remove some

Matt_King: let’s not confuse window discussion with landmark decision

Glen Gordon: we’re all over the map
… what are we discussing? whether to add dialogs to landmarks? separate landmarks into a bunch of modal things?
… what is the question?

Matt_King: first question: should the ARIA spec specify that non-modal dialogs should be treated by AT as landmark regions?
… consensus: no

Glen Gordon: but what about the question around authors treating landmarks in a particular way?

Jamie: pertains to keyboard discussion
… two question that stand out:
… #1) should dialogs be considered landmarks (no)

<Github> https://github.com/w3c/aria/issues/1 : Practices: ALT+del conflicts with JAWS keystroke

Jamie: #2) should ARIA group pursue a keyboard shortcut between dialogs

<Github> https://github.com/w3c/aria/pull/2 : pfwg-action-1415

jamesn: consensus: dialogs should not be landmarks

aaronlev: users can’t easily navigate to modeless dialogs
… still a problem

cyns: need to replace with something else

Jamie: do you want to replace at spec level _or_ just a solution?
… spec does not require anything about headings and yet AT provide heading nav
… we could make recommendation

cyns: also issue for keyboard users

Matt_King: it is not an issue; ARIA does not specify

aaronlev: have a document that makes recommendations to ATs
… we have relationships outside the spec
… want to improve UX

jamesn: NVDA almost has this thing already, it sounds like?
… but shouldn’t be too difficult?
… just no way to get from dialog to dialog
… do AT have appetite to do this?

Glen Gordon: like the idea that there is a browser-provided keystroke
… preferably not F6
… to allow users to move between significant portions of a web app, like dialog
… Tab moves between the chrome and the page content: that is profoundly confusing
… love the idea of there being a key to move between landmarks, but *not* the browser’s chrome

Matt_King: you want to isolate browser from the page even more
… browser is like an OS
… that runs software
… so you should be able to be in a web page and not “fall out” of it
… if I’m in Windows or Linux, I use specific commands to load new apps
… should be same in browser
… if you want to go to a new page, press the command to go to the address bar

jcraig: you want to lock tab loop into a web view?

Matt_King: yes, you would loop back to the beginning of the web view after end
… you could have F6 have its own window ring inside the browser
… F6 is good because it’s predictable

cyns: you don’t want necessarily to track the OS command in the browser also
… need a new command?

sarah_h: common in desktop apps, right?
… I agree: annoying to go into browser chrome out of web view

cyns: sounds like question for user research

sarah_h: people like it now

Glen Gordon: the power of Matt’s proposal is if ARIA parts can change in parallel with browser behavior
… as screen reader vendors, we need to implement this on our own
… probably not a horrible ask
… would be a quicker path than trying to win browsers over

cyns: browsers are in the room

aaronlev: as things stand, plan to implement F6 to navigate to HTML dialogs, but not ARIA
… disturbing, because inconsistent

Matt_King: what would it take for us to move beyond history and figure out how to do what we know people *really* need

note: html is proposing to remove modeless dialogs aren't they?

aaronlev: that’s one deep dive topic: how do we make it so native HTML elements have same good keyboard experience as ARIA (vice versa)

<Zakim> cyns, you wanted to ask how that would impact webviews embedded in apps?

cyns: doesn’t break ARIA principle to add additional keyboard operability

aaronlev: screen readers must provide means to navigate non-modal dialogs

Matt_King: don’t need to put in spec

Jamie: as editorial note?

Matt_King: yes, not normative

cyns: keyboard behavior that’s useful to many people besides screen reader users

jcraig: no problem if other AT vendors want to due what it takes to get it done, but if this were to happen in an Apple product, it'd probably need to be in Safari advanced prefs near the other keyboard focus controls
… as cyns mentioned could be useful to keyboard users too, but it should be a app behavior change, not an AT-based override of full keyboard access
… what is F6?

Jamie: moves between major panels on screen

aaronlev: not like cmd+~

Matt_King: look at doc, in Chrome dev tools on Windows, F6 and Shift+F6 moves between inspector and web view

cyns: less about landmarks
… more about large sections

jamesn: also works on Mac in Chrome and Edge

aaronlev: control+F6 on Mac?

cyns: prototype this in a browser extension

sarah_h: in MS production apps, we use Ctrl+F6 since F6 is already used

Jamie: Slack does that also
… AT should provide mechanism to navigate between dialogs
… dialogs should be treated as having explicit boundaries

aaronlev: would be okay with F6 or something like that if UA was responsible
… could do for ARIA to make consistent with HTML

Jamie: can’t forget about touchscreens

aaronlev: also have to worry about this for manual popups
… very similar to non-modal dialog

Jamie: they’re trickier

jamesn: do we have path forward?

cyns: time to make prototype?

aaronlev: let’s just get down what we need to do
… need to write a design doc for ???

jamesn: UA SHOULD provide mechanism

aaronlev: should get UA implementers to agree

jcraig: this will be met with resistance because one known benefit of ARIA is that it does not change functionality
… adding a11y does not break functionality

Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).

Diagnostics

Succeeded: s/does/is doing/

Succeeded: s/welecom/welcome/

Succeeded: s/futer/future/

Failed: s/o we have conceptual layers to /do we have the conceptual layer to show the architecture?/

Succeeded: s/I'm not su/Nicole: I'm not su/

Succeeded: s/currently/TabAtkins: currently/

Succeeded: s/AP/API/

Succeeded: s/resources/resource/

Failed: s/brain/bryan/

Succeeded: s/@@@/properties/

Succeeded: s/scotto:/scotto: what considerations have been taken with how this would work with various modalities.... /

Succeeded: s/manuel/manual

Succeeded: s/or the informational/for the informational/

Succeeded: s/Supported in WebKit/aria-details supported in WebKit/

Succeeded: s/desigs/designs

Succeeded: s/we can agree/jcraig: We can agree/

Succeeded: s/jamesn/James/

Succeeded: s/aaron,/jcraig:/

Succeeded: s/aaron user/jcraig:/

Succeeded: s/jcraig:/jcraig: user/

Succeeded: s/aaron, not/jcraig: not/

Succeeded: s/back to original proposal/jcraig: back to original proposal/

Succeeded 8 times: s/jamesc:/jcraig:/g

Succeeded: s/and 3/and 4/

Succeeded: s/jamesn/jamie

Succeeded: s/jamesn/jamie/

Succeeded: s/#708/#1708/

Succeeded: s/“google”/“goooooooooooogle”/

Succeeded: s/cyn/cyns/

Succeeded: s/some other/some other key for landmarks/

Succeeded: s/Chrome/chrome/

Succeeded: s/could be useful to many users/as cyns mentioned could be useful to keyboard users too, but it should be a app behavior change, not an AT-based override of full keyboard access/

Succeeded: s/if this were to happen in an Apple product, I’d pick Safari advanced prefs/no problem if other AT vendors want to due what it takes to get it done, but if this were to happen in an Apple product, it'd probably need to be in Safari advanced prefs near the other keyboard focus controls/

Maybe present: aaron, Adma, alex, bryanG, chrishtr, chrisl, curt, cyn, everyone, james, jamesc, jamesn, jamie, jemma, matt, mck, michael, nicole, note, sarah_h, sarahH, Seth, simon, TabAtkins, val, valerie