IRC log of aria on 2022-09-15

Timestamps are in UTC.

15:52:49 [RRSAgent]
RRSAgent has joined #aria
15:52:49 [RRSAgent]
logging to https://www.w3.org/2022/09/15-aria-irc
15:52:51 [Zakim]
RRSAgent, make logs Public
15:52:52 [Zakim]
please title this meeting ("meeting: ..."), jamesn
15:53:24 [jamesn]
meeting: ARAI WG TPAC
15:53:33 [jamesn]
meeting: ARIA WG TPAC (day 1)
15:57:03 [chlane]
chlane has joined #aria
15:57:19 [CurtBellew]
CurtBellew has joined #aria
15:57:30 [mbgower]
mbgower has joined #aria
15:57:36 [mbgower]
present+
15:57:55 [jamesn]
scribe: jamesn
15:58:07 [Adam_Page]
present+
15:58:13 [spectranaut_]
present+ valerie_young
15:59:33 [Matt_King]
Matt_King has joined #aria
16:03:13 [howard-e]
howard-e has joined #aria
16:03:49 [Matt_King]
Slides for aria-at overview:
16:03:51 [aaronlev]
aaronlev has joined #aria
16:03:52 [Matt_King]
https://docs.google.com/presentation/u/0/d/1KuvI1UIctfMvHJeba0WQGie7JoDNqmOLjiFPNFSEv04/htmlpresent
16:03:55 [CurtBellew]
present+
16:03:58 [howard-e]
present+
16:04:10 [Jem]
Jem has joined #aria
16:06:15 [bkardell_]
bkardell_ has joined #aria
16:06:18 [cyns]
cyns has joined #aria
16:06:27 [cyns]
present+
16:07:55 [jamesn]
Seth: ARIA AT is to test interop of AT
16:08:12 [jamesn]
... design patterns are source material of what we are testing
16:08:38 [jamesn]
... process of writing the tests and the expecte3d output. Then there is infrastructure so we can run it on a large scale
16:08:55 [jamesn]
... and for the future figure out how to automate the screen readers
16:09:15 [jamesn]
.... important not just for us but for the web devs etc. too
16:09:31 [jamesn]
... then to share the results and help the community prioritize what bugs to fix
16:09:40 [jamesn]
.... the project is aria-at.w3.org
16:10:02 [jamesn]
... the big goal is so AT users can reliably browse the web
16:10:21 [jamesn]
... also a project to help AT and browser vendors find and priotize bugs
16:11:49 [jamesn]
... 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
16:12:14 [jamesn]
... an example of a test within a test plan. this one had full support in the 3 UA/AT combos tested
16:12:26 [Jem]
present+
16:12:40 [jcraig]
present+
16:12:51 [cyns]
q+ to ask if these are manual or automatic tests
16:12:56 [jamesn]
... we are writing these tests - have drafted tests for 45 of 65 exmaples. Started with what we think are most impactful
16:13:04 [jamesn]
.... collecting manual results
16:13:16 [jamesn]
... 40 tests per test plan with many more assertions
16:13:20 [jcraig]
FYI That dialog escape test should work on iOS too with the VoiceOver "scrub"/"escape" gesture
16:13:38 [jamesn]
... manual resutls from 2 or more individual testers and reviewed until there are no conflicts
16:14:08 [jamesn]
... published first round at aria-at.w3.org/reports
16:14:22 [jamesn]
... meanwhile developing tech to automate
16:14:41 [jamesn]
... lots of effort to build drivers for continuous integration
16:14:59 [zcorpan]
present+
16:15:25 [jamesn]
... hoping thst this automation api would have similar support to webdriver
16:15:33 [jamesn]
...all of that is where we are today
16:15:41 [jamesn]
... bigger vision
16:16:07 [jamesn]
... want to expand test suite to cover all aria roles states and props as well as html exmaples
16:16:20 [jamesn]
... really want to be automating with manual review
16:16:25 [jamesn]
... would allow more data points
16:16:41 [jamesn]
.... once we have a body of test results that represent an accurate report
16:16:49 [jamesn]
... and updated with new AT and browsers
16:17:28 [jamesn]
... and would like these to be syndicated using embedded test results in aria practices
16:17:37 [jamesn]
should put in spec too
16:17:55 [jamesn]
... trying to bring this process earlier in process
16:18:26 [jamesn]
... working on implementation of AT automation in NVDA and later multiple ATs
16:18:56 [jamesn]
... one of the things we want to talk about today is how can fit into the spec process
16:19:14 [cyns]
q?
16:19:21 [cyns]
q-
16:19:34 [jamesn]
Matt_King: key aspect is getting consensus on AT expectations
16:19:47 [jamesn]
Matt_King: for specfic attributes
16:19:57 [jamesn]
Matt_King: so far in non controversial expectations
16:20:09 [jamesn]
Matt_King: much to discuss for things coming
16:20:43 [jamesn]
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
16:21:46 [jamesn]
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
16:21:57 [jamesn]
Matt_King: and ensure we actually solve issues for users
16:22:13 [jamesn]
Matt_King: quite certain wouldn't have created haspopup as we did
16:22:18 [jamesn]
q?
16:22:24 [mbgower]
q+
16:22:26 [cyns]
q+
16:22:42 [Jem]
+q to addess the junction with ongoing "accessibilty supported" discussion in WCAG and implication to future planning of the project sustainabilty
16:23:11 [jamesn]
MichaelC: if we are getting harmoniZation then we could explore having normative requirements
16:23:14 [jamesn]
q+
16:24:03 [jamesn]
mbgower: curveball.... can't have normative language - the power of convention. APG has been powerful in persuading people to adopt patterns
16:24:53 [jamesn]
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
16:25:16 [jamesn]
mbgower: aria patterns can either converge or diverge those cues. Patterns add customized interactions to the patterns
16:25:37 [jcraig]
q+
16:25:38 [jamesn]
mbgower: visually things don't always appear the same. voice or other non screen reader ATs
16:26:27 [jamesn]
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
16:26:35 [jamesn]
ack mbgower
16:26:47 [jamesn]
ack cyns
16:27:07 [jamesn]
cyns: mention to a spec - can someone put in IRC
16:27:21 [jamesn]
jcraig: I am unclear what the repos do
16:27:22 [jcraig]
https://github.com/w3c/aria-at-automation
16:27:27 [jamesn]
ack jcraig
16:27:55 [BGaraventa]
BGaraventa has joined #aria
16:28:14 [jamesn]
Seth: ack Jem
16:28:19 [jamesn]
ack Jem
16:28:20 [Zakim]
Jem, you wanted to addess the junction with ongoing "accessibilty supported" discussion in WCAG and implication to future planning of the project sustainabilty
16:28:27 [jamesn]
q-
16:28:35 [BGaraventa]
present+ bgaraventa
16:28:44 [s3ththompson]
s3ththompson has joined #aria
16:29:08 [jamesn]
Jem: in AG talking about whether going to remove a11y supported clause - junction between AG and Aria-At
16:29:21 [s3ththompson]
AT Automation API repository: https://github.com/w3c/aria-at-automation
16:29:21 [jamesn]
Jem: Shadi tried once for a DB of results
16:29:45 [s3ththompson]
AT Automation API latest preview of draft spec: https://pr-preview.s3.amazonaws.com/w3c/aria-at-automation/pull/25.html
16:30:03 [jamesn]
Jem: focused on major ATs but Japan for example uses different screeen readers
16:30:03 [cyns]
q+
16:30:27 [jamesn]
zakim, close the queue
16:30:27 [Zakim]
ok, jamesn, the speaker queue is closed
16:30:56 [jamesn]
Matt_King: to be sustainable will need more investment over time. at the moment meta funded
16:31:04 [jamesn]
ack cyns
16:31:14 [jamesn]
cyns: all AT or just screen readers?
16:31:20 [jamesn]
Matt_King: all At over time
16:32:34 [jamesn]
scribe+ Jem
16:32:45 [s3ththompson]
ARIA-AT Progress Update slides: https://docs.google.com/presentation/d/1KuvI1UIctfMvHJeba0WQGie7JoDNqmOLjiFPNFSEv04/edit#slide=id.gc6fa3c898_0_0
16:33:02 [Jem]
Topic: scribe+
16:33:03 [Matt_King]
present+
16:33:04 [chlane]
present+
16:33:09 [Jem]
Topic: ARIA/AAM/AccName Group Processes first session
16:33:15 [aaronlev]
present+
16:33:18 [Jem]
scribe+
16:33:18 [Adam_Page]
present+
16:33:50 [spectranaut_]
https://docs.google.com/document/d/14dOVzG-nB1P-uLBET3BYC2v_LvfPpUPWvRfqGLUnBzg/edit#heading=h.wfe18rzby46v
16:33:51 [Jem]
valerie: we have two sessions. one is today and the other will be tomorrow.
16:34:17 [Jem]
... we have document to go through but we can start with self introduction.
16:34:46 [Jem]
one question to be answered during introductiuon is what ARIA is doing good and what ARAI is not doing good.
16:35:49 [Jem]
val: I am Valerie - doign well - positive atmosture not doing well/ interdependency to other spect
16:36:53 [Jem]
jamesn: doing well - we are good at listening to different opinion, not good at is that delivering the outcome in a timely manner
16:37:10 [spectranaut_]
scribe+
16:37:56 [spectranaut_]
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
16:38:04 [spectranaut_]
Jem: what we are not doing well, what is "CR"?
16:38:10 [spectranaut_]
Jem: I don't understand the processes
16:38:29 [Jem]
jamesc: I work on apple accessiblity, he/him.
16:38:41 [MarkMcCarthy]
MarkMcCarthy has joined #aria
16:38:47 [Jem]
one thing aria group does better is mananging the scope creep.
16:38:59 [Jem]
s/does/is doing/
16:39:12 [Jem]
val is doing great as the new chair.
16:39:21 [Jem]
james has been doing great job.
16:39:45 [Jem]
similar to Val's opinion regarding "not doing well' is
16:40:02 [Jem]
tracking the bugs
16:40:13 [Jem]
in a coordinated way
16:40:28 [Jem]
could be the option
16:40:44 [Jem]
aaron: work for Chrome since the first checkbox is implemented.
16:41:16 [Jem]
I rather be careful in delivering spec rather than make them big.
16:41:39 [Jem]
how to manage complex discussion that involves other groups and spec such as css ....
16:41:42 [mbgower]
+1 to aaron
16:41:48 [Jem]
will be important
16:42:07 [Jem]
Adma: I m reletivley new to the group.
16:42:27 [Jem]
everyone: welecom
16:42:36 [Jem]
s/welecom/welcome/
16:43:20 [Jem]
alex: I work for the Boucoup. ARIA is practical and would like to see more architectural limitation.
16:44:05 [Jem]
alex: architectural limitation I meant is ....
16:44:14 [Jem]
@@
16:44:46 [Jem]
chrisl: I am a11y engineer at VMware.
16:44:54 [Jem]
the group is very friedly
16:45:22 [Jem]
...don't have the cristism yet.
16:45:57 [Jem]
markmccarthy: we really work well together in spite that we are the large group.
16:46:27 [Jem]
...challenge may be streamlining the github workflow.
16:46:41 [Jem]
...I work for University of Illinois
16:46:59 [Jem]
simon: work for Bocoup, AT spec proposal
16:47:18 [Jem]
...I like to echo what Alex said.
16:47:51 [Jem]
..accessibility built in process rather that bold on approach will be desirable.
16:48:16 [Jem]
curt: I work for Oracle. he/him
16:48:27 [aaronlev]
Death to ARIA — Long Live ARIA!
16:48:35 [Jem]
... I appriciate the open discussion
16:49:06 [Jem]
sometime I am lost about the W3C terms and acronyms like Jemma addressed.
16:49:18 [Jem]
sarahH: I work for MS and a developer
16:49:25 [Jem]
co-chairs are fantastic.
16:50:10 [Jem]
similar to JamesN said, more timely follow up on github issues and responses will be great, not necessarily shiping the deliverables quickly
16:50:31 [Jem]
seth: I work for Boucoup. ARIA does great job on big pictures which matters.
16:50:45 [howard-e]
howard-e has joined #aria
16:51:13 [Jem]
...improvment can be done on more crossover effeort both APG and HTML
16:51:20 [Jem]
cyn: work for Google.
16:51:58 [Jem]
doing a good job on opening other groups' suggestion.
16:52:08 [Jem]
we still have lot of issues to solve.
16:52:23 [Jem]
.. if we can recruite more member, it will be great.
16:52:27 [scotto]
present+
16:52:33 [Jem]
michael: W3C contact.
16:53:10 [Jem]
... the process - triaging, consensus builing, technically- works very well.
16:53:38 [Jem]
...hard time to draw lines for feature developments
16:53:54 [Jem]
val: aria 1.3 prioritizaiton will be helpful to that point
16:54:25 [Jem]
mck: ARIA is a patienct group - willing to go back and work on the issues
16:55:00 [Jem]
the biggest concerns is growablity of this group - human resource part
16:55:16 [Jem]
more members for wg will be great.
16:56:06 [Jem]
we really need to think about the dept of the group and how to recruit more developers and designer for futer work.
16:56:21 [Jem]
s/futer/future/
16:56:36 [Jem]
bryanG: I work for the Level Accss.
16:56:52 [Jem]
... various spec and the editor for core aam spec
16:57:16 [Jem]
our groups work have impact on the world.
16:57:46 [Jem]
what we can improve is delivering the outcome more timely manner
16:57:56 [chlane]
queue+
16:58:08 [jamesn]
zakim, open the queue
16:58:08 [Zakim]
ok, jamesn, the speaker queue is open
16:58:22 [Jem]
val: summary - good things: good wg enviroment, great chairs..
16:59:26 [jamesn]
https://docs.google.com/document/d/14dOVzG-nB1P-uLBET3BYC2v_LvfPpUPWvRfqGLUnBzg/edit#
16:59:52 [Jem]
things to improve: clarity on the process, working cross with other wgs, and the improvment of work process speed.
17:06:43 [mbgower]
mbgower has joined #aria
17:23:59 [howard-e]
howard-e has joined #aria
17:27:08 [jamesn]
TOPIC: CSS Toggle and CSS-AAM
17:29:53 [bkardell_]
present+
17:29:59 [Adam_Page]
present+
17:30:06 [MarkMcCarthy]
present+
17:30:08 [mbgower]
mbgower has joined #aria
17:30:23 [Jem]
scribe-
17:30:30 [TabAtkins]
TabAtkins has joined #aria
17:30:37 [jcraig]
scribe+
17:30:49 [Jem]
rrsagent, make minutes
17:30:49 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/09/15-aria-minutes.html Jem
17:30:58 [mbgower]
mbgower has joined #aria
17:31:41 [jcraig]
nicole: I'm Chromes PM for Web UI
17:31:47 [TabAtkins]
Spec under discussion: https://tabatkins.github.io/css-toggle/
17:31:48 [sarah_h]
sarah_h has joined #aria
17:31:59 [jcraig]
DOM, Fonts, Interaction, Layout... big areas of work
17:32:10 [jcraig]
I used to think of Accessibility as a risk for my project
17:32:18 [jcraig]
now I think of it as an opportunity
17:32:19 [BGaraventa]
BGaraventa has joined #aria
17:32:42 [jcraig]
Important benefit for use cases and developer outcomes in addition to users
17:32:47 [BGaraventa]
present+ bgaraventa
17:32:56 [mbgower_]
mbgower_ has joined #aria
17:33:13 [jcraig]
web devs have too much to do... (examples) can we make it (a11y etc) easier for them
17:33:33 [cyns]
cyns has joined #aria
17:33:38 [jcraig]
browser should be doing more to ensure a11y w/o needing web devs to become a11y experts
17:33:58 [jcraig]
some web devs have mentioned they don't see a benefit to a11y
17:34:22 [jcraig]
more conscientious devs are concerns b/c they are unsure whether they have gotten it right
17:34:59 [jcraig]
so we (google PM/evangelism) got excited about the ARIA Authoring patterns
17:35:08 [jamesn]
q?
17:35:09 [jcraig]
so CSS toggle came out of that
17:35:45 [jcraig]
Idea that it uses CSS as the primary toggle with accessibility coming along for free
17:36:37 [jcraig]
some interactive components are only modifiable in C++ so difficult to extend…
17:37:08 [jcraig]
JavaScript custom components are easy for devs to write, but devs don't always consider the a11y
17:37:21 [jcraig]
so the goal of CSS toggle is to bridge that gap
17:37:49 [jcraig]
thank you for your feedback and participation in this
17:38:01 [jcraig]
TabAtkins: intro to the spec
17:38:13 [jcraig]
https://tabatkins.github.io/css-toggle/
17:38:28 [TabAtkins]
https://gist.github.com/tabatkins/bda9adac50ba7d5616e60ecce9e5cb30
17:38:49 [jcraig]
another list of Accessibility interaction patterns, and how toggle could benefit those authoring patterns
17:39:05 [jcraig]
google root that sets up a toggle pattern
17:39:17 [chrishtr]
chrishtr has joined #aria
17:39:17 [jcraig]
toggle is visible to the element, siblings, descendants,
17:39:35 [jcraig]
any element can respond to or trigger the :toggle
17:39:47 [miriam]
miriam has joined #aria
17:39:50 [jcraig]
increment, decrement, reset, etc
17:39:58 [miriam]
present+
17:39:58 [jcraig]
most commonly toggle between on/off
17:40:12 [nicole]
nicole has joined #aria
17:40:24 [jcraig]
using this simple pattern, you can implement a wide range of interaction patterns
17:40:53 [jcraig]
sop web devs can easily author, and the UA makes it just work
17:41:19 [jcraig]
automatically exposed in the most common correct pattern
17:41:43 [jcraig]
aaronlev: with the ability to override the UA if needed
17:42:31 [jamesn]
q+
17:42:42 [jcraig]
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...
17:43:29 [jcraig]
TabAtkins: connection between visibility is also apparent to the inference algorithm, so we can make accessible cross refs automatically
17:43:44 [TabAtkins]
via the 'toggle-visibility' property
17:44:49 [jcraig]
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
17:45:17 [scotto]
q+
17:45:25 [jcraig]
jamesn: confused about some points... what about the checkbox example identifies it as a checkbox?
17:45:58 [Adam_Page]
q+
17:46:05 [jcraig]
https://www.irccloud.com/pastebin/dc4wUmeK/
17:46:52 [jcraig]
this will be a togglable.... whether it's a checkbox or switch or pressed button?
17:46:54 [jcraig]
q+
17:47:10 [jcraig]
q+ to ask about whether it's a checkbox or switch or pressed button?
17:47:31 [jcraig]
Nicole: we hope to expand this to other more complex examples
17:47:37 [jamesn]
ack me
17:47:38 [Jem]
o we have conceptual layers to
17:47:51 [jcraig]
as we explore what's right for HTML, for Accessibility, etc
17:48:01 [sarah_h]
q+
17:48:09 [jamesn]
ack scotto
17:48:12 [Jem]
s/o we have conceptual layers to /do we have the conceptual layer to show the architecture?/
17:48:18 [jcraig]
not tied to a particular implementation yet...
17:48:39 [jcraig]
scotto: I noticed in the examples that css generated content was used to render a checkbox icon
17:49:30 [Jem]
great question, Scott.
17:49:36 [jcraig]
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
17:49:37 [Matt_King]
Matt_King has joined #aria
17:50:49 [jcraig]
cyns: that sounds like a requirement... label inference from the generated content?
17:51:26 [Matt_King]
q+
17:51:39 [jcraig]
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
17:51:52 [jcraig]
s/I'm not su/Nicole: I'm not su/
17:52:18 [nicole]
This is my nic
17:52:44 [jcraig]
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
17:53:21 [jcraig]
there is no content model for CSS, so unexpectedly nested intractables need mitigation details
17:54:05 [jcraig]
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.
17:54:10 [zcorpan]
Spec issue for links in <summary>: https://github.com/whatwg/html/issues/2272
17:54:36 [jcraig]
we want to be consistent how we handle this similarly to other poorly nested HTML
17:54:38 [jamesn]
q?
17:55:24 [jcraig]
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
17:55:37 [Matt_King]
q?
17:55:58 [jcraig]
scotto: clarifying... CSS toggle on link,,, both a link and checkbox. which wins out?
17:56:19 [jcraig]
currently it is not allowed to put toggle props on interactive elements
17:56:33 [jcraig]
s/currently/TabAtkins: currently/
17:56:54 [jcraig]
but open question about an interactive inside a toggle
17:57:05 [jcraig]
scotto: or making a table a toggle
17:57:41 [cyns]
q+
17:57:44 [jcraig]
Adam_Page: does the first example have its role inferred as generic?
17:58:04 [jcraig]
TabAtkins: whatever the simplest toggle is. maybe checkbox.
17:58:17 [bkardell_]
q+
17:59:05 [jcraig]
TabAtkins: the names don't matter, but the interaction matters... self activator... strong signal that its a checkbox
17:59:13 [jcraig]
ack Adam_Page
17:59:21 [jcraig]
ack me
17:59:21 [Zakim]
jcraig, you wanted to ask about whether it's a checkbox or switch or pressed button?
17:59:26 [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
17:59:33 [howard-e]
howard-e has joined #aria
18:00:43 [spectranaut_]
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
18:00:43 [spectranaut_]
the bigger picture.
18:00:48 [Jem]
+1 jamesC
18:00:53 [spectranaut_]
jcraig: it's nice we can have overrides, but people might want to
18:01:20 [chrishtr]
q+
18:01:27 [jcraig]
jamesn: if you are overriding the role, how would you override the associated attires... e.g. pressed versus checked
18:01:35 [tzviya]
tzviya has joined #aria
18:01:37 [Matt_King]
q-
18:01:56 [jcraig]
TabAtkins: overriding the role could also handle the API property diff in the AP
18:02:02 [jcraig]
s/AP/API/
18:02:36 [jamesn]
ack sarah_h
18:02:47 [scotto]
i talk too much
18:03:01 [jcraig]
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.
18:03:52 [jcraig]
sarah_h: if someone applies toggle to a focusable, or changes the css class, does it change the interaction or focusability change?
18:04:21 [jcraig]
TabAtkins: you can't remove a toggle able via CSS. so can't get into a view dependency loop..
18:04:35 [jcraig]
can only remove via JavaScript
18:04:41 [scotto]
q+
18:05:02 [jcraig]
TabAtkins: toggles are created as stable state on the element... even a change to the selector later will be ignored.
18:05:09 [jamesn]
ack cyns
18:05:21 [Jem]
is the toggle like a temporarily mediator?
18:05:37 [Adam_Page]
q+
18:05:40 [jcraig]
cyns: documenting what this does should be mapping guide or some other critical resources
18:05:52 [jcraig]
s/resources/resource/
18:06:00 [jamesn]
ack bkardell_
18:06:14 [jcraig]
bkardell_: difficult to comment on some things without details
18:06:31 [jcraig]
what more can you share about the inference algorithm idea
18:06:54 [jcraig]
TabAtkins: no more details fleshed out yet... still working on it
18:06:54 [Jem]
that is a good rephase of my prior question - inference process, Brain
18:07:07 [Jem]
s/brain/bryan/
18:07:12 [jcraig]
Nicole: and I'm keeping them on track ;-)
18:07:31 [jamesn]
zakim, close the queue
18:07:31 [Zakim]
ok, jamesn, the speaker queue is closed
18:07:36 [jamesn]
q?
18:07:46 [jcraig]
bkardell_: what could change? you said CSS class state changes would be ignored, but could DOM references change?
18:07:54 [cyns]
q+ to say should the inference algorithm be specified (like HTML) or the outcomes like AAM
18:07:54 [jamesn]
ack chrishtr
18:08:00 [jcraig]
chrishtr: Nice to meet you all. first time with ARIA
18:08:08 [jcraig]
(welcome from all)
18:08:39 [jcraig]
why not have a shorthand like "I'm a checkbox" and have the rest be inferred
18:09:27 [jcraig]
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
18:09:29 [Jem]
at least, this idea might help mobile UI.
18:09:58 [jcraig]
instead of saying toggle.. have a CSS property value of checkbox, so the trigger is the role nudge
18:10:34 [jcraig]
aaronlev: the developer would use the "checkbox" because they would get all the interaction for free
18:11:01 [Jem]
+1 christr
18:11:02 [jamesn]
q?
18:11:07 [sarah_h]
q+
18:11:15 [jcraig]
TabAtkins: that's for clarifying... these are split between selectors and @@@ and many are multiple elements, so can't apply via a single attr
18:11:22 [jamesn]
ack scotto
18:11:23 [jcraig]
scotto:
18:11:33 [TabAtkins]
s/@@@/properties/
18:11:52 [TabAtkins]
TabAtkins: But difficulties don't mean impossible, especially for simple cases like checkbox this might be possible
18:12:11 [jcraig]
s/scotto:/scotto: what considerations have been taken with how this would work with various modalities.... /
18:12:28 [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.
18:12:33 [jcraig]
scotto: eg. reader mode. styles would go away.
18:13:21 [jcraig]
not saying conflicts would exist, but people do style their controls in certain ways. this may complicate their existing usage
18:13:42 [jcraig]
what happens when the user needs a feature this pattern would break?
18:13:49 [jamesn]
q?
18:14:39 [jcraig]
TabAtkins: partial answer... Reader Mode: I don't believe they ignore all markup...
18:14:45 [Jem]
+1 to scott addressing the basic principle of accessibilty, it is not only about the visual.
18:14:50 [jcraig]
scotto: e.g. display:none would be ignored in reader mode
18:15:22 [jcraig]
TabAtkins: developers of these tools (like Safari reader mode) may have to update to incorporate toggles
18:15:34 [bkardell_]
also print*
18:15:43 [jamesn]
ack Adam_Page
18:15:51 [jcraig]
scotto: seems like reader mode should need to change to respect author style
18:16:02 [jcraig]
Adam_Page: how about CSSS specificity?
18:16:19 [jcraig]
TabAtkins: that will create a new toggle
18:16:37 [sarah_h]
q+
18:16:39 [jcraig]
jamesn: what about CSS-AAM, cyns?
18:16:46 [jongund]
jongund has joined #aria
18:16:59 [Adam_Page]
the `toggle` property can be overridden by more specific selectors
18:17:08 [jcraig]
cyns: are you documenting the inference algorithm, API output, or both?
18:17:46 [jcraig]
cyns: many people will be confused by the algorithm, so it needs to be well documented and clear
18:18:07 [jcraig]
cyns: hope a CSS-AAM plan emerges from this
18:18:51 [jcraig]
for example, css toggle, css order, when the CSS tree should change the a11y API tree...
18:19:06 [jcraig]
sighted keyboard users would also see some layouts as backwards
18:19:55 [jcraig]
jamesn: CSS specs say "don't use these layout patterns" if AT order is important, but devs do it anyway
18:20:20 [jcraig]
nicole: review spicy sections in Open UI
18:20:28 [jcraig]
cyns: nods to bkardell_
18:21:02 [jcraig]
jamesn: does anyone in CSS disagree that a CSS Accessibility API Mapping (AAM) guide is needed?
18:21:27 [Jem]
The documentation Cyn mentions will be great.
18:21:44 [jcraig]
nicole: first step my be the use cases list. start with the highest priority.
18:22:22 [jcraig]
jamesn: should this be a breakout document or should each live in relevant part of the CSS spec
18:22:46 [jcraig]
jcraig: my vote is to keep as much CSS Accessibility info in the core CSS spec for the featyre
18:23:30 [jcraig]
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?
18:24:59 [Holli]
Holli has joined #ARIA
18:25:10 [jcraig]
process discussion about how to raise CSS issues for cross ARIA group review
18:25:53 [cyns]
q+ to suggest a community group for CSS A11y
18:26:03 [jamesn]
zakim, open the queue
18:26:03 [Zakim]
ok, jamesn, the speaker queue is open
18:26:22 [TabAtkins]
q+
18:26:58 [chrishtr]
Being discussed right now in csswg: https://github.com/w3c/csswg-drafts/issues/7387
18:27:01 [chrishtr]
q+
18:27:20 [chrishtr]
q-
18:29:15 [jcraig]
scribe-
18:30:43 [aaronlev]
Popup API explainer: https://open-ui.org/components/popup.research.explainer
18:32:54 [chlane]
scribe+
18:33:12 [jamesn]
topic: Popup Attributes
18:33:25 [sarah_h]
scribe+
18:33:27 [chlane]
scribe-
18:33:36 [jamesn]
rrsagent, make minutes
18:33:36 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/09/15-aria-minutes.html jamesn
18:34:37 [sarah_h]
aaronlev: how many people have had a chance to take a look?
18:35:06 [sarah_h]
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
18:35:18 [Adam_Page]
present+
18:35:34 [sarah_h]
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
18:36:10 [sarah_h]
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
18:36:17 [Jem]
or the informational purpose, Sarah also worked/coordinated two tooltip meetings
18:36:21 [sarah_h]
aaronlev: the popup attr values are manuel popup and hint
18:36:26 [Jem]
for APG
18:36:32 [sarah_h]
s/manuel/manual
18:36:47 [Jem]
s/or the informational/for the informational/
18:36:58 [sarah_h]
aaronlev: an auto popup is something you trigger by clicking something like a button, and tabbing out will auto-dismiss
18:37:17 [sarah_h]
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
18:37:32 [sarah_h]
aaronlev: you can kind of mix and match some of the attrs that trigger things, or different popups in different ways
18:37:50 [sarah_h]
scotto: that's a good high level overview. To touch on the thing you mentioned about it moving over to this from an element
18:38:39 [sarah_h]
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
18:39:00 [aaronlev]
Accessibility proposals for popup:
18:39:05 [aaronlev]
https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit#heading=h.7fodzd7pkxs0
18:39:19 [Matt_King]
q?
18:39:26 [TabAtkins]
q-
18:39:36 [sarah_h]
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
18:39:58 [sarah_h]
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.
18:40:24 [sarah_h]
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
18:40:44 [sarah_h]
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
18:41:36 [sarah_h]
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
18:42:11 [sarah_h]
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
18:42:53 [Matt_King]
q+
18:42:59 [sarah_h]
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
18:43:11 [sarah_h]
aaronlev: and a hint popup would get a minimum role of tooltip.
18:43:14 [jcraig]
so <div popup> would be mapped to group in HTML-AAM?
18:43:23 [jcraig]
seems reasonable
18:43:28 [jamesn]
q?
18:43:40 [sarah_h]
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
18:44:07 [sarah_h]
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
18:44:45 [sarah_h]
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
18:44:51 [jamesn]
q?
18:44:54 [sarah_h]
cyns: anyone know how well aria-details is supported?
18:45:23 [sarah_h]
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
18:45:38 [jamesn]
ack Matt_King
18:46:41 [jcraig]
Supported in WebKit/VO. WebKit diff at https://bugs.webkit.org/show_bug.cgi?format=multiple&id=165842
18:46:48 [sarah_h]
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]
18:47:03 [jcraig]
s/Supported in WebKit/aria-details supported in WebKit/
18:47:23 [sarah_h]
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
18:47:28 [sarah_h]
Matt_King: it just confuses the heck out of people
18:48:05 [sarah_h]
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
18:48:13 [jcraig]
short link of above https://webkit.org/b/165842
18:48:21 [cyns]
q?
18:48:40 [sarah_h]
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
18:48:57 [sarah_h]
Matt_King: try to scope it in ways where we're making sure we're not introducing complex controversial or new long-term problems
18:49:15 [sarah_h]
aaronlev: I'll let Nicole talk about the user research part of it
18:49:57 [sarah_h]
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
18:50:17 [scotto]
q+
18:50:29 [cyns]
q+
18:50:41 [sarah_h]
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
18:51:11 [sarah_h]
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
18:51:44 [sarah_h]
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
18:52:32 [sarah_h]
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
18:52:54 [sarah_h]
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
18:53:41 [Jem]
q+ 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?
18:53:47 [sarah_h]
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
18:54:02 [sarah_h]
Matt_King: ok, maybe no one likes tooltips :D
18:54:21 [sarah_h]
cyns: there's a user researcher on my team who has experience doing studies with users with disabilities who might have time
18:54:28 [Jem]
I liked the discussion of potential dom order.
18:54:30 [sarah_h]
cyns: that's a great way to affect desigs
18:54:31 [cyns]
q-
18:54:34 [sarah_h]
s/desigs/designs
18:54:38 [jamesn]
ack scotto
18:55:42 [sarah_h]
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]
18:56:07 [chrishtr]
q+
18:56:15 [jamesn]
ack Jem
18:56:15 [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
18:56:18 [Zakim]
... not be covered by aria-details. or will it be covered by aria-details?
18:56:23 [Matt_King]
q?
18:56:27 [sarah_h]
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
18:57:00 [Matt_King]
q+
18:57:12 [TabAtkins]
TabAtkins has left #aria
18:57:31 [sarah_h]
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?
18:57:42 [sarah_h]
aaronlev: like an interactive grid?
18:57:43 [sarah_h]
Jem: yes
18:58:19 [sarah_h]
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
18:58:24 [jamesn]
ack chrishtr
18:58:36 [jamesn]
zakim, close the queue
18:58:36 [Zakim]
ok, jamesn, the speaker queue is closed
18:58:58 [sarah_h]
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?
18:59:01 [sarah_h]
Matt_King: not necessarily
18:59:13 [sarah_h]
aaronlev: they are exposed in a way users can filter them out
18:59:27 [sarah_h]
chrishtr: they may not be, depending on how they're implemented
18:59:39 [sarah_h]
aaronlev: with the hint proposal, they'd be exposed in the same way as the title attr
19:00:04 [sarah_h]
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
19:00:15 [sarah_h]
Matt_King: I'm more concerned about the interactivity baked into this
19:00:17 [jamesn]
ack Matt_King
19:02:42 [sarah_h]
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
19:03:35 [sarah_h]
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
19:03:42 [sarah_h]
jcraig: role or something else?
19:03:48 [sarah_h]
aaronlev: I think an attribute
19:04:17 [Jem]
yes. I also heard a lot of complaints that people get lost a lot with pop up.
19:04:18 [sarah_h]
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
19:04:31 [rego_]
rego_ has joined #aria
19:04:32 [sarah_h]
aaronlev: we have to talk about initial focus, F6 with async popups, what happens on page load
19:04:38 [jcraig]
aaronlev: bikeshed aria-island
19:04:40 [jcraig]
got it. a interaction primitive similar to modal
19:05:03 [sarah_h]
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?
19:05:15 [sarah_h]
aaronlev: Let me go through some of the TBDs here
19:05:48 [sarah_h]
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
19:05:51 [Matt_King]
q+
19:05:54 [sarah_h]
q+
19:05:55 [jamesn]
zakim, open the queue
19:05:56 [Zakim]
ok, jamesn, the speaker queue is open
19:05:56 [sarah_h]
q+
19:06:00 [Matt_King]
fq+
19:07:00 [scotto]
q+
19:07:14 [sarah_h]
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.
19:07:43 [sarah_h]
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.
19:08:13 [sarah_h]
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
19:08:25 [sarah_h]
Matt_King: it's something to consider. But if you can't tab out, should you be able to tab into something.
19:08:41 [jamesn]
ack scotto
19:09:20 [sarah_h]
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
19:10:11 [sarah_h]
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
19:10:16 [jamesn]
ack sarah_h
19:10:28 [chlane]
scribe+
19:11:07 [chlane]
scotto: clashes with aria owns
19:11:13 [sarah_h]
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
19:11:15 [chlane]
can't reuse that code
19:11:20 [sarah_h]
aaronlev: yeah, I've spent a year fixing bugs with aria-owns
19:11:35 [sarah_h]
aaronlev: this seemed like a place to increase the value of aria-details, because we're going to need that
19:11:42 [Jem]
I am thinking that 'light dismiss" may violate WCAG in regards to conginitive disability although I cannot think of specific SC right now.
19:12:27 [sarah_h]
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
19:12:36 [sarah_h]
aaronlev: are there any objections to doing it this way for now?
19:12:53 [sarah_h]
Matt_King: the current explainer, is that on a wiki now?
19:13:05 [sarah_h]
aaronlev: I'm talking about the google doc I emailed earlier today to the public aria WG
19:13:10 [Jem]
what is this then, https://open-ui.org/components/popup.research.explainer?
19:13:25 [aaronlev]
https://docs.google.com/document/d/1umackdZ9wZsr0cJtM6IfpFLN0RJKCypdYiRe_nJuk8c/edit#
19:13:27 [sarah_h]
aaronlev: I've written a popup a11y proposal
19:13:31 [sarah_h]
jamesn: can you put a link in IRC?
19:13:50 [Jem]
Thanks for the google doc, @aaron
19:14:12 [sarah_h]
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
19:14:24 [sarah_h]
Matt_King: can we add a link to the google doc from the explainer?
19:14:38 [sarah_h]
scotto: I don't see why that would be a problem
19:27:51 [howard-e]
howard-e has joined #aria
19:32:58 [mbgower]
mbgower has joined #aria
19:51:12 [howard-e]
howard-e has joined #aria
19:52:41 [MichaelC]
MichaelC has joined #aria
20:02:01 [mbgower]
mbgower has joined #aria
20:05:00 [MichaelC]
present+
20:08:43 [howard-e]
howard-e has joined #aria
20:22:44 [Matt_King]
Matt_King has joined #aria
20:27:29 [howard-e]
howard-e has joined #aria
20:43:54 [jamesn]
TOPIC: How to handle unlabeled elements
20:46:08 [Jamie]
Jamie has joined #aria
20:46:24 [chlane]
scribe+
20:46:37 [jamesn]
zakim, open the queue
20:46:37 [Zakim]
ok, jamesn, the speaker queue is open
20:46:46 [sarah_h]
sarah_h has joined #aria
20:46:49 [chlane]
How to handle unlabelled elements
20:46:51 [chlane]
https://github.com/w3c/accname/issues/138
20:47:33 [Holli]
Holli has joined #ARIA
20:47:42 [chlane]
we can agree on some changes then discuss
20:48:06 [chlane]
user jumped into articles with article rotor
20:48:13 [chlane]
see a heading that would useful
20:48:16 [chlane]
makes sense
20:48:26 [chlane]
dissallowed to pass up in browser
20:48:30 [chlane]
CSS prevented
20:48:43 [chlane]
intial issue was heuristics will get better
20:48:50 [chlane]
is an auth error
20:49:03 [chlane]
ARIA wanted something rigid
20:49:13 [chlane]
name from heading is a good idea
20:49:17 [jongund]
jongund has joined #aria
20:49:17 [chlane]
everone agrees
20:49:42 [chlane]
ML heuristics should be better
20:50:00 [jcraig]
Original Issue https://github.com/w3c/accname/issues/138
20:50:11 [chlane]
#138 in accname
20:50:11 [Github]
https://github.com/w3c/aria/issues/138 : HTML-AAM: audio UIA should have localized control type
20:50:17 [jamesn]
rragent, make minutes
20:50:19 [chlane]
aria issue #899
20:50:19 [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
20:50:23 [jamesn]
rrsagent, make minutes
20:50:23 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/09/15-aria-minutes.html jamesn
20:50:44 [jcraig]
Old PR from Jon https://github.com/w3c/aria/pull/1018/files
20:50:49 [chlane]
repo accname 138
20:50:52 [chlane]
aria 1018
20:51:11 [chlane]
feedback on #1018
20:51:11 [Github]
https://github.com/w3c/aria/pull/1018 : Issue899 accname from heading
20:51:15 [jamesn]
s/we can agree/jcraig: We can agree/
20:51:26 [chlane]
aaron will take over
20:51:37 [chlane]
couple of things need agreement
20:52:08 [chlane]
most cruft and whitespace diffs
20:52:08 [BGaraventa]
BGaraventa has joined #aria
20:52:34 [BGaraventa]
present+ bgaraventa
20:53:23 [chlane]
no nesting with landmark roles
20:53:33 [chlane]
think it is unecessary
20:53:36 [leobalter]
leobalter has joined #aria
20:53:45 [chlane]
any objections?
20:53:57 [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."
20:54:03 [chlane]
Matt_King: role=region object doing this at all
20:54:13 [chlane]
ok for other
20:55:09 [Jem]
https://raw.githack.com/w3c/aria/issue899-accname-from-heading/index.html#namecalculation
20:56:16 [chlane]
jamesn: why label complimentary?
20:56:28 [chlane]
or nav
20:56:36 [chlane]
if there is a label we can read that
20:56:57 [chlane]
Matt_King:useless to hear complimentary
20:57:12 [chlane]
jamesn: risk 1st heading could be halfway down
20:57:26 [chlane]
aaron, heuristics better than first child
20:57:31 [chlane]
come back to that
20:58:28 [chlane]
remove 'A heading can only be used to name its nearest ancestor element that follows from heading"
20:58:52 [chlane]
overcomplicates implementation causes slowdown
20:59:05 [chlane]
simplifying John's PR
20:59:14 [chlane]
Matt_King: what are the side effects?
20:59:28 [chlane]
if its a sloppy page or incomplete implementation
20:59:29 [jongund]
jongund has joined #aria
20:59:38 [chlane]
2 nested containers could share a label
20:59:40 [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.
21:00:01 [chlane]
redundant for user in worst case
21:00:25 [chlane]
sarah_h: content region 1st article has a heading,
21:00:30 [chlane]
like and landmark region
21:01:20 [chlane]
jamesn: 6 roles to get name from heading
21:01:41 [chlane]
alertdialog,article, dialog,complimentary,navigation,region
21:02:04 [chlane]
aaron changing what name from heading means
21:02:21 [chlane]
aaron DPUB roles they want
21:02:39 [chlane]
jamesn: if you have a heading no need to provide a name
21:02:45 [chlane]
Matt_King: don't go down that path
21:03:08 [Jem]
Now I understand what two jamesn meant "simplify"
21:03:08 [chlane]
concensuss for removing
21:03:15 [chlane]
'A heading can only be used to name its nearest ancestor element that follows from heading"
21:03:21 [Jem]
s/jamesn/James/
21:04:04 [chlane]
Matt_King: if you are using region you should know name is required
21:04:22 [chlane]
author should be listed before heading
21:04:31 [chlane]
big removal
21:04:59 [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
21:04:59 [jcraig]
contained in the first element with a role of heading, authors SHOULD reference the visible label with <pref>aria-labelledby</pref>"
21:05:22 [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.
21:06:47 [chlane]
aaron, this is for the authoring spec
21:06:55 [chlane]
Matt_King: if this is error correction we don't need this
21:07:20 [chlane]
why would'nt we allow authors to label with a child header
21:07:33 [chlane]
authors will accidentally get it right
21:07:34 [Jamie]
If it's not error correction, then the possibility of a heading halfway down a landmark is pretty worrying.
21:07:47 [chlane]
Matt_King: what the specific requirements should be
21:08:01 [chlane]
what qualifies as label from child heading
21:08:20 [chlane]
dialog > p > heading a label will be needed
21:08:32 [chlane]
jamesn: entire <p> is meaningless
21:08:54 [chlane]
a "duh" requirement
21:09:04 [chlane]
concencus to remove?
21:09:05 [chlane]
yes
21:09:17 [chlane]
Matt_King: confused if we are going in 2 directions
21:11:01 [chlane]
line 6552
21:11:08 [jamesn]
q?
21:12:23 [chlane]
jamesn: sections aren't landmarks unless they are labelled otherwise you have unintended landmarks
21:12:47 [chlane]
non proliferation
21:13:12 [jamesn]
q?
21:13:26 [chlane]
Matt_King: dialogs
21:13:46 [chlane]
Matt_King: this isn't error correction
21:13:59 [chlane]
this becomes a name technique
21:13:59 [Jamie_]
Jamie_ has joined #aria
21:15:20 [chlane]
Matt_King: concerned about the ability to detect articles/dialogs that are missing labels
21:15:27 [chlane]
if the heading is not a good label
21:15:39 [sarah_h]
q+
21:15:52 [chlane]
and we just pulled out the structural requirements
21:15:55 [jamesn]
q+
21:16:21 [chlane]
with no author MUST related to structure
21:16:31 [chlane]
you can't to check to see if is is labelled
21:16:42 [chlane]
aaron,you can check
21:16:51 [chlane]
Matt_King: not for an intentional label
21:17:12 [chlane]
jamesn: technically valid
21:17:25 [chlane]
same tool cannot check for correct img alt text
21:17:39 [chlane]
Matt_King: at least the author tried to specifiy alt text
21:17:46 [chlane]
in this case the author did nothing
21:17:54 [chlane]
aaron
21:18:03 [chlane]
golive required alt text
21:18:12 [chlane]
and authors used "."
21:18:33 [cyns]
cyns has joined #aria
21:18:39 [chlane]
Matt_King: we don't have a problem of "." for a dialog heading
21:18:50 [cyns]
q?
21:18:54 [chlane]
the heading may not be a good label
21:18:58 [cyns]
q+
21:19:00 [chlane]
no author MUST
21:19:10 [chlane]
is a problem
21:19:18 [chlane]
aaron aknowledged
21:19:30 [chlane]
authors won't use checking tools
21:19:35 [chlane]
Matt_King: we build them
21:19:50 [chlane]
Matt_King: we could make our own internal rules but not a good idea
21:20:12 [chlane]
aaron, the reason this exists is the 99% is the best guess
21:20:28 [chlane]
Matt_King: satisfying name is requiered is what I'm talking about it
21:20:37 [spectranaut_]
s/aaron,/jcraig:/
21:20:37 [chlane]
aaron user over authors
21:20:53 [chlane]
still say the change is worthwhile
21:21:05 [spectranaut_]
s/aaron user/jcraig:/
21:21:12 [jamesn]
ack sarah_h
21:21:24 [chlane]
sarah_h: scott tested role=region exposing nameless regions
21:21:44 [chlane]
don't think 1st heading is the right solution but it might be worth reconsidering
21:21:48 [jamesn]
q-
21:21:49 [spectranaut_]
s/jcraig:/jcraig: user/
21:22:11 [chlane]
scott comment 8/1/2019 on the PR
21:22:15 [chlane]
Matt_King: going back
21:22:23 [chlane]
no longer agrees with concensus
21:22:47 [chlane]
agree with error correction
21:23:12 [chlane]
jamesn: authors must ensure the first header must be a meaningful name
21:23:23 [chlane]
naive checkers won't know what is meaningful
21:23:50 [chlane]
jamesn: article 1 article 2 is worse than first heading
21:24:13 [chlane]
aaron, not going to commit this
21:24:21 [chlane]
just clean up this diff
21:24:36 [jamesn]
s/aaron, not/jcraig: not/
21:24:48 [chlane]
Matt_King: there could be middle ground if we can get a preview working
21:25:00 [chlane]
back to original proposal
21:25:21 [chlane]
error scenario, name from heading solve these cases
21:25:23 [jamesn]
q?
21:25:31 [chlane]
the reason I put this there
21:25:54 [chlane]
ML techniques are changing how AT accross the board
21:26:04 [chlane]
aknowledge in spec
21:26:23 [chlane]
to let browsers provide the best thing to the user
21:26:42 [chlane]
jamesn: can you provide the language that prevents this?
21:26:52 [spectranaut_]
s/back to original proposal/jcraig: back to original proposal/
21:27:14 [Holli]
Holli has joined #ARIA
21:27:15 [chlane]
jamesn: AT corrects things, why is this different?
21:28:24 [chlane]
webkit or VO has to cheat
21:28:37 [chlane]
jamesn: can solve without spec changes
21:28:45 [chlane]
expose as guessname
21:29:32 [chlane]
Matt_King: it should still have no name in the a11y tree
21:29:47 [Jamie_]
That also allows AT to differentiate a guess from reality, which could be useful to tell the user that it might be problematic.
21:29:55 [jamesn]
ack cyns
21:30:53 [cyns]
scribe+
21:31:04 [jamesn]
topic: text separation
21:32:05 [cyns]
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
21:33:00 [cyns]
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
21:33:02 [sarah_h]
https://github.com/w3c/aria/pull/996
21:33:06 [mbgower]
mbgower has joined #aria
21:34:10 [cyns]
jamesc: 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
21:34:39 [cyns]
jamesc: some ppl didn't think span and role should be the same, so we did text separation
21:35:01 [cyns]
jamesn: now that we have generic, what problem is text separation trying to solve that a real world developer has?
21:35:27 [cyns]
jamesn: solves teh same thing as text=static (sp?) changing how strings are read
21:35:55 [cyns]
jamesn: propose that we don't do aria text separation and bring back a form of role text status
21:36:21 [cyns]
matt: the problem is that a role change changes the role, but a property allows ...
21:36:34 [cyns]
jamesn: role=text is a specialized version of role=generic
21:36:52 [cyns]
jamesn: apple has role=text implemented in webkit. Have their been problems with it?
21:38:17 [cyns]
jamesc: 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
21:39:23 [cyns]
jamesc: problem is with an implementation or role=text that makes children presentational. Changing behavior of role=text problem
21:39:37 [cyns]
matt: back to the problem
21:40:05 [cyns]
jamesn: where does text separation go? overly complex for the problem it's trying to solve
21:40:45 [cyns]
jamesc: problems with implementation with os accessibility apis having to look at sibilings
21:40:53 [cyns]
cyns: sounds like performance problem
21:41:19 [cyns]
jamesn: Only textual contents allowed (author error)
21:42:28 [cyns]
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
21:42:41 [cyns]
matt: That is still the problem that we're trying to solve
21:42:52 [cyns]
matt: need to look at list of practical use cases
21:43:05 [cyns]
q?
21:43:09 [cyns]
q+
21:44:00 [jamesn]
ack cyns
21:44:31 [spectranaut_]
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...
21:44:52 [spectranaut_]
jamesn: maybe not, because that discussion was adding pauses on purposes
21:45:18 [spectranaut_]
jamesn: where this is just a word getting put in different blocks unrelated to the author content
21:45:31 [cyns]
ok
21:45:58 [cyns]
matt: when you have a kbb element inside a sentence, you're reading the sentence and then it stops
21:46:08 [cyns]
jamesc: read from here can pass that
21:46:25 [jamesn]
q+ to suggest a path forward
21:46:28 [cyns]
jamesc: kbb is there for a reason, which is why there's a pause to let the user know
21:47:05 [jamesn]
ack me
21:47:05 [Zakim]
jamesn, you wanted to suggest a path forward
21:47:19 [cyns]
matt: one example of a use case
21:47:49 [jcraig]
discussion was about multiple interaction patterns for navigating inline content that is styled differently for a reason. like <kbd>
21:47:53 [cyns]
jamesn: we should close the text separation issue, it's not useful or implentable. Anyone disagree
21:48:13 [cyns]
jamesn: open a new issue with the fundamental use cases we're trying to solve
21:48:37 [jcraig]
I mentioned to Matt_King that VO+A (Ctrl+Opt+a or CapLock+a) continues reading a the end of each inline element
21:48:42 [cyns]
jamesn: create a draft PR for role=static
21:49:00 [cyns]
matt: didn't go to children
21:49:20 [cyns]
jamesn: could have test tools and maybe UA not expose if there are the wrong children
21:49:22 [jcraig]
s/jamesc:/jcraig:/g
21:49:34 [cyns]
matt: we can look at the pr proposal
21:50:06 [cyns]
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
21:51:47 [cyns]
matt: example I (heart emoji) NY got read as I love New York, no way to know that there was a heart emoji
21:52:26 [cyns]
jamesn: maybe we can find a way to resolve objections, or maybe not and it's still worth moving forward
21:52:48 [cyns]
matt: yes, but look out for side effects
21:53:27 [cyns]
jamesc: Jamie, last night we talked about Scotts PR suppressing role description. That is what it's doing. The primary benefit is simplifying implemntiona
21:53:46 [cyns]
jamie: commented on PR, it's ok
22:03:31 [mbgower]
mbgower has joined #aria
22:05:24 [mbgower]
mbgower has joined #aria
22:17:15 [mbgower]
mbgower has joined #aria
22:30:32 [jamesn]
topic: What to do with name prohibited?
22:33:52 [Holli]
Holli has joined #ARIA
22:34:35 [cyns]
cyns has joined #aria
22:34:39 [cyns]
scribe-
22:34:51 [spectranaut_]
scribe+
22:35:26 [spectranaut_]
jamesn: in 1.2 we introduced a new category of roles, name prohibited
22:35:32 [Matt_King]
Matt_King has joined #aria
22:35:49 [spectranaut_]
jamesn: for things that could not be names, like generic and paragraph, things that generally only contain text or are generic containers
22:35:59 [spectranaut_]
jamesn: in 1.2 it wasn't a problem, it was only author requirements
22:36:28 [spectranaut_]
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
22:36:58 [spectranaut_]
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
22:37:02 [spectranaut_]
jamesn: but why?
22:37:04 [sarah_h]
sarah_h has joined #aria
22:37:44 [spectranaut_]
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
22:38:14 [spectranaut_]
jamesn: so we went down that path, but we got a lot of feedback, like the ones linked in the agenda
22:38:28 [spectranaut_]
jamesn: some of the issues are when a generic or prohibited becomes focusable
22:38:43 [spectranaut_]
jamesn: seems like name could be a good fallback in this scenario
22:39:05 [spectranaut_]
jamesn: I believe the user agent implementors were reluctant to implement
22:39:46 [spectranaut_]
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
22:40:01 [spectranaut_]
aaron: a lot of authors only know about aria-label and its a bandaid and they are trying to annotate
22:40:02 [jcraig]
https://github.com/w3c/aria/issues/1487
22:40:10 [spectranaut_]
aaron: it happens often enough I think we should allow it
22:40:32 [spectranaut_]
aaron: now that we don't prohibit it, we have inconsistent screen reader behavior
22:40:56 [spectranaut_]
jamesn: chrome started to implemented "do not expose name when prohibited" then it encountered problems, so they didn't implement
22:41:18 [spectranaut_]
jamesn: so we don't have implementations of the 1.3 specification, unless implementors agree to implement, we have to remove it
22:41:19 [jcraig]
https://github.com/w3c/aria/issues/1476
22:41:30 [jcraig]
https://docs.google.com/document/d/1mcce70oxAl03_P6uzWldZ2nhGHoteaMlpVl5KWszFdk/edit?usp=sharing&resourcekey=0-zjDvv9ENpmNvJeX4TFTfsg
22:41:36 [spectranaut_]
jamesn: all three linked bugs are essentially the same issue
22:41:48 [aaronlev]
aaronlev has joined #aria
22:41:54 [aaronlev]
https://docs.google.com/document/d/16AysDIyGt7IfazLmLP8wFsnTTBFKWPDBA50z9LDm6tA/edit#
22:42:24 [spectranaut_]
aaronlev: I had some discussions with jamie about the problem and this is the result ^
22:42:47 [spectranaut_]
aaronlev: proposal, keep exposing it as an accessible name, and trying to convince ATs to expose
22:42:59 [spectranaut_]
aaronlev: next proposal, ....?
22:43:10 [spectranaut_]
aaronlev: next proposal, expose the name as "aria-description"
22:43:26 [spectranaut_]
aaronlev: next proposal, if on a generic element, then do a repair and have a minimum role of group
22:43:36 [spectranaut_]
Matt_King: I feel like all of those....
22:43:44 [spectranaut_]
Matt_King: I don't understand second proposal
22:44:12 [spectranaut_]
aaronlev: second proposal... I can't quite remember, jamie do you remember you have a blog post
22:45:18 [spectranaut_]
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
22:45:30 [spectranaut_]
Matt_King: we shouldn't change things so that authors can name them
22:45:41 [spectranaut_]
jamesn: validators flag it as an error!
22:45:49 [Jamie]
q+
22:45:56 [spectranaut_]
Matt_King: what do you mean keep on doing what we are doing?
22:46:12 [spectranaut_]
aaronlev: we should be strict about what we require and loose in what we prohibit
22:46:27 [spectranaut_]
aaronlev: and instead try to repair
22:47:28 [spectranaut_]
jamesn: how are we going to move forward to get 1.3 out?
22:47:40 [spectranaut_]
jamesn: we need to remove the user agents must not
22:47:59 [spectranaut_]
jamesn: user agents need to do something for error correction purposes
22:48:18 [spectranaut_]
Matt_King: can we say "may not" instead of "must not" because then they don't need to expose as an accessible name
22:48:50 [spectranaut_]
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
22:49:22 [spectranaut_]
jamesn: that ok?
22:49:46 [spectranaut_]
james: we won't forget about the issue and make it clear to readers of the spec that the discussion is on going
22:49:57 [spectranaut_]
jamesn: also I'd like to have more editors notes to describe things that are in flux
22:50:07 [spectranaut_]
Jamie: I would object to the statement remaining in the spec
22:50:33 [spectranaut_]
jamesn: we almost got agreement to remove the statement in a previous meeting, I just wanted to confirm it with more people
22:50:53 [spectranaut_]
no objections
22:51:15 [spectranaut_]
jamesn: so lets discussion options for the long term solution?
22:51:49 [spectranaut_]
jamesn: back to aaron's document
22:51:56 [spectranaut_]
jamesn: three options
22:52:45 [spectranaut_]
Matt_King: I think 1 and 3 are problematic
22:53:18 [spectranaut_]
s/and 3/and 4/
22:53:31 [spectranaut_]
Matt_King: I think 3 is ok, with "name-from:prohibited-name"
22:53:54 [spectranaut_]
Matt_King: one pro that is not listed is that the aria label will not be treated by name calculation as a name
22:54:20 [spectranaut_]
Matt_King: so in the accessibility inspector will not show a name
22:54:45 [spectranaut_]
aaronlev: it will show in the description, and under the reason it will say where we got it from
22:54:59 [spectranaut_]
Matt_King: I like that because it is explicit
22:55:16 [spectranaut_]
Matt_King: if that results in duplicative speech, that is an good result, because you did something you were not suppose to do
22:55:41 [spectranaut_]
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
22:55:56 [spectranaut_]
Jamie: it is not a given that an AT will read a description
22:56:31 [spectranaut_]
Jamie: it is not defined that a AT will handle a name in a particular way in the name prohibited case
22:56:55 [spectranaut_]
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
22:57:32 [spectranaut_]
Jamie: it's tricky. if it is what the author misguidedly intented.... it seems like it is also misleading to expose as a description
22:57:39 [jamesn]
q?
22:57:40 [spectranaut_]
Matt_King: but we do that already with a whole bunch of stuff
22:58:05 [spectranaut_]
Matt_King: some times a name is a name sometimes it is a description. I think we are talking more about authors than users
22:58:24 [spectranaut_]
jamesn: this is like a guess. we should expose it as something different and AT can do what they want
22:58:37 [spectranaut_]
Jamie: this is error correction, always carries some risk and is hard
22:58:54 [spectranaut_]
jamesn: this is "an invalid name" should be exposed
22:59:25 [spectranaut_]
aaronlev: if we move to aria description, ats are working on trying to do this consistently,
22:59:53 [spectranaut_]
jamesn: so we should use description instead of making a new idea because that will take forever to get AT support
23:00:05 [spectranaut_]
Matt_King: I think this is the best for users and lease confusing for authors
23:00:35 [spectranaut_]
Jamie: as much as I expose to role="text" people use it because they want that behavoir
23:01:34 [spectranaut_]
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
23:01:44 [jamesn]
ack Jamie
23:02:08 [spectranaut_]
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
23:02:19 [spectranaut_]
Matt_King: we don't want to fix every anti-pattern
23:02:32 [spectranaut_]
jamesn: we don't want to prevent at and browsers repairing things
23:03:05 [bkardell_]
q+
23:03:12 [spectranaut_]
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
23:03:17 [jamesn]
zakim, close the queue
23:03:17 [Zakim]
ok, jamesn, the speaker queue is closed
23:03:21 [spectranaut_]
aaronlev: I'm pretty sure most of them are not empty
23:03:48 [spectranaut_]
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
23:04:18 [spectranaut_]
jamesn: I think we are overloading annotations
23:04:32 [spectranaut_]
s/jamesn/jamie
23:04:33 [spectranaut_]
s/jamesn/jamie/
23:04:40 [Jamie]
q-
23:04:53 [spectranaut_]
jamesn: thanks everyone!
23:05:02 [spectranaut_]
TOPIC: dialogs
23:05:29 [bkardell_]
can I just ask "would you like me to get an answer to the previous question from the http archive dataset?"
23:06:04 [Adam_Page]
scribe+
23:06:23 [Adam_Page]
Matt_King: there was homework for this
23:06:32 [Adam_Page]
... kind of long, so here’s some help
23:07:12 [Adam_Page]
... there is an issue in ARIA #708 referring to non-modal / modeless dialogs being treated by screen readers
23:07:13 [Github]
https://github.com/w3c/aria/pull/708 : IDL attribute reflection branch
23:07:19 [Adam_Page]
... there was a proposal that they be recognized as landmark in regions
23:07:22 [Adam_Page]
... in #1708
23:07:23 [Github]
https://github.com/w3c/aria/issues/1708 : tracking issue for <dialog> & role=dialog
23:07:31 [Adam_Page]
... I did not support, and wrote a counter proposal
23:07:36 [spectranaut_]
s/#708/#1708/
23:07:37 [Github]
https://github.com/w3c/aria/pull/708 : IDL attribute reflection branch
23:07:38 [Github]
https://github.com/w3c/aria/issues/1708 : tracking issue for <dialog> & role=dialog
23:07:45 [jamesn]
zakim, open the queue
23:07:45 [Zakim]
ok, jamesn, the speaker queue is open
23:07:56 [Adam_Page]
... the net of this is that we need a different kind of container available to authors
23:08:06 [Adam_Page]
... very different from landmark regions, in order to solve pressing problems
23:08:16 [Adam_Page]
... things we can do in native software, but not on the web today
23:08:24 [Adam_Page]
... essentially create an application with multiple windows
23:08:27 [Adam_Page]
... where each window is a non-modal dialog
23:08:53 [cyns]
cyns has joined #aria
23:08:55 [Adam_Page]
... in this proposal, I made up some new terminology
23:09:04 [Adam_Page]
... to describe how screen readers present different containers
23:09:11 [Adam_Page]
... kind of screen reader CSS if you will
23:09:16 [jamesn]
q- bkardell_
23:09:19 [Adam_Page]
... solid, porous, and hidden
23:09:24 [Adam_Page]
... read doc to understand
23:09:39 [Adam_Page]
... the one that matters for now is that screen readers treat modals as if they have solid boundaries
23:10:13 [Adam_Page]
... 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
23:10:27 [Adam_Page]
... on web page with many landmark regions, you’ll see all on the page
23:10:39 [Adam_Page]
... and can easily navigate to next item across region boundaries
23:10:48 [Adam_Page]
... but non-modal dialogs are not the same
23:11:01 [Adam_Page]
... the proposal is to have screen readers treat non-modals the same ways modals
23:11:23 [Adam_Page]
... and have the same expectation for non-modals on the web that we have for inter-app windows, modeless windows, etc. within native application
23:11:40 [Adam_Page]
... or the OS/browser presents a way to navigate between currently open non-modal windows
23:11:52 [Adam_Page]
... an opportunity to solve real challenging usability problems on the web
23:11:59 [Adam_Page]
... currently no way to do this
23:12:04 [Adam_Page]
... e.g., comments sidebar in Google Docs
23:12:44 [Adam_Page]
... 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
23:12:53 [Jamie]
q+
23:13:19 [Adam_Page]
... what should this mean in terms of spec language?
23:13:28 [Adam_Page]
... some specific ideas for things to be done by screen readers and browsers
23:13:43 [Adam_Page]
... there’s a WHATWG issue related to deprecating dialog.show
23:13:53 [Adam_Page]
... would not want to deprecate if we pursue this
23:14:08 [Adam_Page]
... so definitely consequences in HTML, unsure of what it would mean for ARIA spec
23:14:22 [Adam_Page]
... dialog is a child of window and doesn’t matter whether it’s modal or non-modal
23:14:34 [jamesn]
ack Jamie
23:14:40 [Adam_Page]
Jamie: thanks for summary
23:14:47 [Adam_Page]
... couple clarifying questions:
23:15:04 [Adam_Page]
... we’re talking about HTML element and role both
23:15:13 [Adam_Page]
... F6 is somewhat browser-centric, implemented by engine
23:15:22 [Adam_Page]
... could be overridden by JS, but should you?
23:15:35 [Adam_Page]
... are keyboard shortcuts _spec’d_ in ARIA?
23:16:20 [Adam_Page]
Matt_King: normative: authors are expected to manage focus, but not specific shortcuts
23:16:32 [Adam_Page]
Jamie: how we do keyboard stuff for dialog might need to be different because of F6
23:16:45 [Adam_Page]
... flagging keyboard-specific spec risks
23:16:52 [Adam_Page]
... a lot of behavior is at AT level
23:16:52 [jamesn]
q?
23:17:08 [Adam_Page]
Matt_King: I don’t know if we would want to add specific language to dialog role description
23:17:15 [Adam_Page]
... to put expectations on AT
23:17:18 [jamesn]
q+
23:17:21 [Adam_Page]
... to depend on modality
23:17:34 [Adam_Page]
Jamie: the spec can’t currently require an AT, so it would be a recommendation
23:17:45 [Adam_Page]
... in general, more unbounded regions don’t seem like a good thing
23:17:53 [Adam_Page]
... we have enough unbounded things as it is, users can get lost
23:18:16 [Adam_Page]
... devil’s advocate: your proposal assumes users find desktop apps _easier_ to navigate. Not necessarily true
23:18:42 [Adam_Page]
... in Narrator, having Scan access in any app gives advanced users freedom
23:18:54 [Adam_Page]
... less advanced users are not aware
23:19:17 [Adam_Page]
... touch screen screen readers may be less efficient, but flicking left & right is easy
23:19:40 [Adam_Page]
Matt_King: that assumption is true for some users *but* native solution does not address problems of solid boundaries for all users
23:19:43 [Adam_Page]
... and we can do a better job on the web
23:19:54 [Adam_Page]
... I have a “google” of ideas
23:20:07 [Adam_Page]
s/“google”/“goooooooooooogle”/
23:20:20 [jamesn]
q?
23:20:41 [Adam_Page]
... can better support users if a screen reader offered “insert R” to change restriction level
23:20:52 [Adam_Page]
... no good reason not to allow easy changing of restriction
23:21:10 [Adam_Page]
Jamie: NVDA for example treats all dialog boundaries as solid
23:21:34 [Adam_Page]
Matt_King: you’re already doing this?!
23:21:46 [Adam_Page]
Jamie: does anyone disagree with assertion that dialogs shouldn’t be landmarks>
23:22:14 [Adam_Page]
jamesn: easiest to get things done. If we don’t have appetite for it, then landmark is easy pragmatic solution
23:22:37 [Adam_Page]
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
23:22:55 [Adam_Page]
... 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
23:23:22 [Adam_Page]
jamesn: if they shouldn’t be a landmark, what should they be?
23:23:28 [Adam_Page]
Jamie: a little controversy here
23:23:38 [Adam_Page]
... ATs have to treat it as a landmark because of the spec
23:24:02 [Adam_Page]
... putting it in spec as landmark sets up restriction that we cannot move past
23:24:08 [Adam_Page]
jamesn: seems fair
23:24:26 [chlane]
o
23:24:35 [Adam_Page]
aaronlev: what are we putting in as replacement?
23:24:39 [Adam_Page]
Jamie: dialogs are dialogs
23:24:51 [Adam_Page]
aaronlev: if there were 2 or 3 modeless dialogs on page...?
23:25:00 [Adam_Page]
Jamie: depends on whether you want to go into F6 territory
23:25:11 [Adam_Page]
aaronlev: ARIA doesn’t drive keyboard behavior
23:25:31 [Adam_Page]
Jamie: if I were making this decision for NVDA, I would include dialogs in the landmark nav command
23:25:32 [Adam_Page]
... BUT
23:25:42 [Adam_Page]
... they wouldn’t expand their content into the document, which landmarks _do_
23:25:53 [Adam_Page]
... they would not have porous bounce (?)
23:26:15 [Adam_Page]
... when it’s in the spec as a landmark it has to be treated with a porous boundary
23:26:17 [jamesn]
q?
23:26:19 [jamesn]
ack me
23:26:22 [Adam_Page]
Matt_King: that raises interesting questions
23:27:07 [Adam_Page]
... is the web mature enough now that we can actually talk about another mechanism besides tabindex
23:27:24 [Adam_Page]
... that would allow a behavior like F6, like “window ring” or some command
23:27:42 [Adam_Page]
... what would the mechanism be for adding something to the HTML/browser
23:27:55 [Adam_Page]
cyn: tabindex is in HTML spec
23:28:01 [Adam_Page]
s/cyn/cyns/
23:28:27 [Adam_Page]
Matt_King: if window ring also included landmarks, then each window could cause a whole bunch of landmarks
23:28:30 [Adam_Page]
Jamie: huge can of worms
23:28:45 [Adam_Page]
Matt_King: in game+chat, you just want to F6 back and forth really quick
23:29:01 [Adam_Page]
cyns: there would be Tab and F6 and some other
23:29:18 [Adam_Page]
jamesn: let’s not discuss mechanisms, there could be more than keyboard
23:29:23 [spectranaut_]
s/some other/some other key for landmarks/
23:29:51 [Adam_Page]
jamesn: how can we get browsers to implement these things?
23:30:01 [Adam_Page]
cyns: landmark nav and something like F6
23:30:15 [Adam_Page]
... don’t know how hard it is to implement. There’s UI in addition to web platform
23:30:23 [Adam_Page]
aaronlev: it’s more philospohical purity
23:30:33 [Adam_Page]
... when we first did ARIA, we did it in one browser
23:30:55 [Adam_Page]
... 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
23:31:09 [Adam_Page]
... ARIA does not affect how things are clicked on; tabindex came from HTML
23:31:21 [Adam_Page]
... ARIA is always an override for semantics
23:31:32 [Adam_Page]
... HTML in ARIA changed that
23:31:41 [Adam_Page]
... nice to be able to say “ARIA does not implement your widget for you”
23:31:47 [Adam_Page]
... philsophical purity is not always what’s best for user
23:33:38 [Adam_Page]
aaronlev: they are adding focus group to HTML
23:33:45 [Adam_Page]
cyns: maybe this feature belongs in HTML and not ARIA
23:33:58 [Adam_Page]
aaronlev: but then some people will put that on their landmark and some won’t
23:34:16 [Adam_Page]
Matt_King: some authors will and some won’t. Important design decision
23:34:31 [jamesn]
q+
23:34:51 [Adam_Page]
Jamie: this is not a new problem
23:35:16 [Adam_Page]
jamesn: if people have too many landmarks, better to remove some
23:35:26 [jamesn]
ack me
23:35:31 [Adam_Page]
Matt_King: let’s not confuse window discussion with landmark decision
23:35:54 [Adam_Page]
Glen Gordon: we’re all over the map
23:36:22 [Adam_Page]
... what are we discussing? whether to add dialogs to landmarks? separate landmarks into a bunch of modal things?
23:36:27 [Adam_Page]
... what is the question?
23:36:50 [Adam_Page]
Matt_King: first question: should the ARIA spec specify that non-modal dialogs should be treated by AT as landmark regions?
23:37:00 [Adam_Page]
... consensus: no
23:37:26 [Adam_Page]
Glen Gordon: but what about the question around authors treating landmarks in a particular way?
23:37:34 [Adam_Page]
Jamie: pertains to keyboard discussion
23:37:41 [Adam_Page]
... two question that stand out:
23:37:46 [Adam_Page]
... #1) should dialogs be considered landmarks (no)
23:37:50 [Github]
https://github.com/w3c/aria/issues/1 : Practices: ALT+del conflicts with JAWS keystroke
23:38:07 [Adam_Page]
...#2) should ARIA group pursue a keyboard shortcut between dialogs
23:38:08 [Github]
https://github.com/w3c/aria/pull/2 : pfwg-action-1415
23:38:19 [Adam_Page]
jamesn: consensus: dialogs should not be landmarks
23:38:36 [Adam_Page]
aaronlev: users can’t easily navigate to modeless dialogs
23:38:38 [Adam_Page]
... still a problem
23:38:43 [Adam_Page]
cyns: need to replace with something else
23:38:57 [Adam_Page]
Jamie: do you want to replace at spec level _or_ just a solution?
23:39:08 [Adam_Page]
... spec does not require anything about headings and yet AT provide heading nav
23:39:19 [Adam_Page]
... we could make recommendation
23:39:34 [Adam_Page]
cyns: also issue for keyboard users
23:39:44 [Adam_Page]
Matt_King: it is not an issue; ARIA does not specify
23:40:11 [Adam_Page]
aaronlev: have a document that makes recommendations to ATs
23:40:21 [Adam_Page]
... we have relationships outside the spec
23:40:31 [Adam_Page]
... want to improve UX
23:40:47 [Adam_Page]
jamesn: NVDA almost has this thing already, it sounds like?
23:40:55 [Adam_Page]
... but shouldn’t be too difficult?
23:40:55 [Adam_Page]
... just no way to get from dialog to dialog
23:41:01 [Adam_Page]
... do AT have appetite to do this?
23:41:14 [Adam_Page]
Glen Gordon: like the idea that there is a browser-provided keystroke
23:41:18 [Adam_Page]
... preferably not F6
23:41:29 [Adam_Page]
... to allow users to move between significant portions of a web app, like dialog
23:41:42 [Adam_Page]
... Tab moves between the Chrome and the page content: that is profoundly confusing
23:42:05 [Adam_Page]
... love the idea of there being a key to move between landmarks, but *not* the browser’s chrome
23:42:12 [Adam_Page]
s/Chrome/chrome/
23:42:27 [Adam_Page]
Matt_King: you want to isolate browser from the page even more
23:42:30 [cyns]
q+ to ask how that would impact webviews embedded in apps?
23:42:36 [Adam_Page]
... browser is like an OS
23:42:38 [Adam_Page]
... that runs software
23:42:51 [Adam_Page]
... so you should be able to be in a web page and not “fall out” of it
23:43:19 [Adam_Page]
... if I’m in Windows or Linux, I use specific commands to load new apps
23:43:35 [Adam_Page]
... should be same in browser
23:43:44 [Adam_Page]
... if you want to go to a new page, press the command to go to the address bar
23:44:11 [Adam_Page]
jcraig: you want to lock tab loop into a web view?
23:44:34 [Adam_Page]
Matt_King: yes, you would loop back to the beginning of the web view after end
23:44:54 [Adam_Page]
... you could have F6 have its own window ring inside the browser
23:45:18 [Adam_Page]
... F6 is good because it’s predictable
23:45:35 [Adam_Page]
cyns: you don’t want necessarily to track the OS command in the browser also
23:45:39 [Adam_Page]
... need a new command?
23:45:53 [Adam_Page]
sarah_h: common in desktop apps, right?
23:46:09 [Adam_Page]
... I agree: annoying to go into browser chrome out of web view
23:46:28 [Adam_Page]
cyns: sounds like question for user research
23:46:34 [Adam_Page]
sarah_h: people like it now
23:47:03 [Adam_Page]
Glen Gordon: the power of Matt’s proposal is if ARIA parts can change in parallel with browser behavior
23:47:10 [Adam_Page]
... as screen reader vendors, we need to implement this on our own
23:47:22 [Adam_Page]
... probably not a horrible ask
23:47:35 [Adam_Page]
... would be a quicker path than trying to win browsers over
23:47:42 [Adam_Page]
cyns: browsers are in the room
23:47:46 [spectranaut_]
present+ glen_gordon
23:47:58 [Adam_Page]
aaronlev: as things stand, plan to implement F6 to navigate to HTML dialogs, but not ARIA
23:48:04 [Adam_Page]
... disturbing, because inconsistent
23:48:27 [Adam_Page]
Matt_King: what would it take for us to move beyond history and figure out how to do what we know people *really* need
23:48:27 [jcraig]
q?
23:48:32 [jamesn]
note: html is proposing to remove modeless dialogs aren't they?
23:48:32 [jcraig]
q+
23:49:01 [Adam_Page]
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)
23:49:08 [jamesn]
ack cyns
23:49:08 [Zakim]
cyns, you wanted to ask how that would impact webviews embedded in apps?
23:49:20 [Adam_Page]
cyns: doesn’t break ARIA principle to add additional keyboard operability
23:49:31 [Adam_Page]
aaronlev: screen readers must provide means to navigate non-modal dialogs
23:49:40 [Adam_Page]
Matt_King: don’t need to put in spec
23:49:48 [Adam_Page]
Jamie: as editorial note?
23:49:54 [Adam_Page]
Matt_King: yes, not normative
23:50:02 [jamesn]
ack jcraig
23:50:07 [Adam_Page]
cyns: keyboard behavior that’s useful to many people besides screen reader users
23:50:26 [Adam_Page]
jcraig: if this were to happen in an Apple product, I’d pick Safari advanced prefs
23:50:37 [Adam_Page]
... could be useful to many users
23:50:46 [cyns]
q+
23:51:00 [Adam_Page]
... what is F6?
23:51:07 [Adam_Page]
Jamie: moves between major panels on screen
23:51:22 [Adam_Page]
aaronlev: not like cmd+~
23:51:56 [Adam_Page]
Matt_King: look at doc, in Chrome dev tools on Windows, F6 and Shift+F6 moves between inspector and web view
23:52:05 [Adam_Page]
cyns: less about landmarks
23:52:11 [Adam_Page]
... more about large sections
23:52:19 [Adam_Page]
jamesn: also works on Mac in Chrome and Edge
23:52:28 [Adam_Page]
aaronlev: control+F6 on Mac?
23:53:11 [Adam_Page]
cyns: prototype this in a browser extension
23:53:30 [Adam_Page]
sarah_h: in MS production apps, we use Ctrl+F6 since F6 is already used
23:53:33 [Adam_Page]
Jamie: Slack does that also
23:53:56 [Adam_Page]
... AT should provide mechanism to navigate between dialogs
23:54:03 [Adam_Page]
... dialogs should be treated as having explicit boundaries
23:54:05 [jcraig]
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/
23:54:15 [jamesn]
q?
23:54:28 [cyns]
q-
23:54:34 [Adam_Page]
aaronlev: would be okay with F6 or something like that if UA was responsible
23:54:46 [Adam_Page]
... could do for ARIA to make consistent with HTML
23:55:17 [Adam_Page]
Jamie: can’t forget about touchscreens
23:55:29 [Adam_Page]
aaronlev: also have to worry about this for manual popups
23:55:33 [Adam_Page]
... very similar to non-modal dialog
23:55:35 [Adam_Page]
Jamie: they’re trickier
23:55:43 [Adam_Page]
jamesn: do we have path forward?
23:55:46 [Adam_Page]
cyns: time to make prototype?
23:55:53 [Adam_Page]
aaronlev: let’s just get down what we need to do
23:56:01 [Adam_Page]
... need to write a design doc for ???
23:56:01 [jcraig]
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/
23:56:54 [Adam_Page]
jamesn: UA SHOULD provide mechanism
23:57:04 [Adam_Page]
aaronlev: should get UA implementers to agree
23:57:26 [Adam_Page]
jcraig: this will be met with resistance because one known benefit of ARIA is that it does not change functionality
23:57:32 [Adam_Page]
... adding a11y does not break functionality
23:57:49 [jamesn]
rrsagent, make minutes
23:57:49 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/09/15-aria-minutes.html jamesn