Meeting minutes
<Matt_King> Slides for aria-at overview:
<Matt_King> https://
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://
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://
Jem: Shadi tried once for a DB of results
<s3ththompson> AT Automation API latest preview of draft spec: https://
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://
scribe+
ARIA/AAM/AccName Group Processes first session
<spectranaut_> https://
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://
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://
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> https://
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://
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://
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://
<aaronlev> Popup API explainer: https://
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:
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://
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://
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://
<aaronlev> https://
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://
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://
#138 in accname
<Github> https://
rragent, make minutes
aria issue #899
<Github> https://
<jcraig> Old PR from Jon https://
repo accname 138
aria 1018
feedback on #1018
<Github> https://
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://
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://
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://
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://
jamesn: all three linked bugs are essentially the same issue
<aaronlev> https://
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://
Matt_King: there was a proposal that they be recognized as landmark in regions
… in #1708
<Github> https://
Matt_King: I did not support, and wrote a counter proposal
<Github> https://
<Github> https://
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://
Jamie: #2) should ARIA group pursue a keyboard shortcut between dialogs
<Github> https://
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