TPAC 2022 - ARIA (day 2)

16 September 2022


ada, Adam_Page, atsushi, AvneeshSingh, bgaraventa, bkardell_, cabanier, CharlesL, chlane, CurtBellew, cyns, DavidFazio, Fazio, GeorgeK, gpellegrino, jamesn, janina, jasonjgw, Jem, JohnRochford, Judy, Leonard, Lionel_Wolberger, marcosc, matatk, Matt_King, MichaelC, NeilS, Piotr_Bialecki, spectranaut_, Tatsuya_Igarashi, yonet
bkardell_, chlane, cyns, jamesn, spectranaut_

Meeting minutes

<Jamie> Food for thought: "It is recommended that assistive technologies (user agents?) provide a mechanism to allow navigation between dialogs. It is recommended that dialogs be treated as a solid boundary (clarify), where a mechanism is provided to explicitly navigate outside of the dialog."

DPub-ARIA roles

<spectranaut_> relevant github issue: https://github.com/w3c/aria/issues/1643

jcraig: So first learned about this from tzviya at Lisbon

jcraig: big misunderstanding - we shipped the first implementation. understanding was more simple

jcraig: since then more functionality and expanded to browsers etc..,.. good intentions but some fragmentation has started to occur

jcraig: we want to ensure we are not doing too much. some most important work is the work you don't put in


<Jem> https://github.com/w3c/aria/issues/1643

<Github> https://github.com/w3c/aria/issues/1643 : Figure out what to do with the DPUB mappings overlap with the ARIA Core spec, in the context of newer implementation differences

jcraig: what to do with the DPUB mapping etc.

the implementation changes were having a custom role and role description for every role.

jcraig: all the specific links instead of being link would be more verbose like 'bibliography reference'

breaks screen reader users "muscle memory"

so biblio refs, footnote refs etc. were implemented in at least one browser at the platform level used a role description

jcraig: dpub folks all weighed in and went back and forth. got pretty complicated

jcraig: i posted a proposal

jcraig: then others went back to the dpub wg and organized a set of prioritizations

jcraig: think i understand it

jcraig: not going to read them all - as a lot there

jcraig: so combining that list with some context

so yesterday got this new proposal - https://github.com/w3c/aria/issues/1643#issuecomment-1248814811

Matt_King: what is your overall objective

<spectranaut_> jcraig reference the original prioritization of roles from DPUB is listed in this comment: https://github.com/w3c/aria/issues/1643#issuecomment-1038828578

jcraig: not to annoy screen reader users

jcraig: appendix is labeled with an appendix heading as it normally has a visible label

jcraig: some folks still think what i propose is too much

jcraig: coming closer to a compromise solution

jcraig: don't need a new role unless there is ????

jcraig: relevance and semantics are important to publsihing industry but not the lay user

Matt_King: fundamentally talking about expectations for how AT conveys roles

Matt_King: in IA2 and UIA not a role description....

jcraig: how it is comveyed to users is what i mean by role description

Matt_King: aria doesn't say what AT should do with a role

jamesn: the role that is exposed by the aams does not necessarily match what the AT says, that is not specified


Matt_King: one of the areas where it is important (ARIA-AT) will talk about whether we should expose certain roles

Matt_King: role explosion doesn't serve all users the same

Matt_King: made a great point about publishers (in industry) vs common consumers

jcraig: but not just publishers but also librarians etc may want different info

jcraig: all these changes were in dpub-aam in MacOS that is role description in UIA localized control type

CharlesL: want to make it clear that epub and a11y TF do not need to have the description say certain things, We just need to be able to expose these roles as subroles of the superclass... just need to dig in through the API and configure the reading system to do something

CharlesL: we just want the DPUB roles exposed. we want the AT to deal with i18n - if don't have that info then can't know where we are

jamesn: clarification, do you need access in the accessibility API? is that what you need?

jamesn: some access needed

you do not need a11y api info

james will reconcile on its own

jamesn: infrastructure needs it but not getting it from a11y api

spectranaut_: what info are you trying to get to them

Jamesc: whereami command

CharlesL: in a reading system could ask where am I - could get that information from anywhere. The other is that the AT might want to automatically announce when going into something.

jamesc hotkey to expose info

make sure does not end up as Epub api that does not directly benefit users

jcraig: epub reader has full access to the DOm and potentially the a11y API too

jcraig: expose uncomputed role string

pick and choose case by case

jcraig: maybe it would be easier if we just exposed the uncomputed role string to APIs

jamesn: coreaam pass through all

<Jem> scribe?

AvneeshSingh: epub reading system can get from markup but as jcraig was mentioning our focus is on AT. first example is for doc-abstract.

AvneeshSingh: reads examples from table

AvneeshSingh: how would AT know that it is an abstract

AvneeshSingh: this info should be in the a11y api so screen readers can query the AX Api and know what it is

AvneeshSingh: the ARIA WG doesn't define the UX - the AX API should be expoising those roles - and then up to screen readers to determine how to expose them

AvneeshSingh: some may expose in different verbosity levels

AvneeshSingh: in discussion how to implement

AvneeshSingh: need the APi to expose

AvneeshSingh: just to alrify

<Zakim> jcraig, you wanted to react to spectranaut_ to respond re: aam and api design

jcraig: good example of my core disagreement is that for most of them the content makes it very obvious

jcraig: as the user comes to the abstract or the acknowledgement it is obvious - but sometimes not always the case

jcraig: collectively we should expose more but not in agreement exactly how much more

jcraig: all these apis ahve made different design choices. one apple made is not forcing conditionality into ATs

jcraig: at least 40 ATs in our products

letting AT work it out would be 40 times the work

jcraig: some API decisions - VO doesn't have any voice strings. but the role descriptions come from the apps or the frameworks

jcraig: don't want to put everything in the API and let them work it out

<cyns> +100 to jcraig

Matt_King: is there a special need within publishing for machines to know stuff - when I naviagte a book and go to Heading Acknowledgments I don't need anuything wrapped around that to know what it is

Matt_King: are there specific fucntions within ereaders - is it to create speach or to enable functionality

Matt_King: assumotion that all the roles that are there have to be announced

gpellegrino: normally epub readers are based in 90% of cases on web views as an implementation technique. I don't know how they can add stuff based on roles. the fact that dpub is implemented by major browsers is important.

acj jcraig

<Zakim> jcraig, you wanted to move back to the agenda... reading the shared agreements and discussing the open questions

jcraig: epub reader has full access - the DOM isn't accessible to the epub reader - seems like there is something sitting onto of the renderer

gpellegrino: something we have to check

jcraig: any native app that renders a web view can reach into that webview

<chlane> o09:34 < jamesn> jcraig: any native app that renders a web view can reach into that webview

GeorgeK: simple docs may not need many of these things. Complex docs like textbooks with many chapters etc.
… an item may or may not say chapter etc. but as you move from place to place in a complex book may get lost. The where am I system is very useful

GeorgeK: If I see that there is a link it is very helpful to know it is a footnote etc. and the semantics presented to an end user should be able to be specified in the screen reader

GeorgeK: we don't have verbosity settings for <p>

<Jem> I hear from George that even link role in epub has the structural points.

CharlesL: right now in web have back button. epub reading systems don't have that

<Jem> and navigational aspect.

CharlesL: knowing where going to go is useful

jcraig: seemed like implemetnation bugs to me not spec issues

jcraig: got to shared understanding

jcraig: lets hold tangential comments

jcraig: hoepfully time left at end for deeper questions

<Jem> +1 for keeping the discussion to the core suggestions.

Consider as new Core Roles in ARIA main spec (in any case, map the doc-prefixed roles to AAM with new role/subrole and role description)



doc-subtitle: Is this sufficiently different from heading? [Update: @scottaohara says yes, would help with https://github.com/indicate what to do with multiple headings in hgroup html-aam#398 ]


jcraig: ARIA WG should consider pulling these in as core roles... still with synonyms for old ones

jcraig: link roles - useful in axapi to serve a different subrole but roledescription would still be link

jcraig: backlink could activate a scrub gesture

<CharlesL> +1

jcraig: then hopefully the label of the link could still make it obvious where going

jcraig: next ones - keep in dpub - but might need custom role descriptions

jcraig: next set - keep in dpub but would be exposed as a region or group but would have the subrole

jcraig: then the rest were from AvneeshSingh less important list so not as important to remap so would be left identical to the superclass role and just exposed as a region in a11y api

jcraig: then some specific questions for the rest

jcraig: maybe exposing the uncomputed role string is good. on mac by default with most controls get the label first then button - on some we push the role first - like links

jcraig: becuase it is before label needs to stay short and consistent

jcraig: don't want to break that usage pattern

jcraig: could do more at the end but don't have that API now

jcraig: GeorgeK mentioned paragraphs - would be annoying...

jcraig: some things could be available on demand... could come to a compromise on some of these

CharlesL: like that - agree

CharlesL: like idea - happy and the least work for devs all for it

jcraig: specific questions....

jcraig: (Charles mentioned Wednesday he wanted to keep these; but Avneesh's WG prioritization list above indicates low importance)



jcraig: Charles mentioned okay to skip, but above Avneesh ranked these higher.


<Zakim> gpellegrino, you wanted to reply on pagelist

gpellegrino: pagelist is consumed by the screenreader then some calculation and then displayed to end user

gpellegrino: important to epub reader but less important to end user

jcraig: no reason to map differently as epub readers display already

AvneeshSingh: want to highlight the priority list was the list the community created in the TF - it is not my understanding but is all the groups understanding

AvneeshSingh: would like to stick with that

<Jem> so my question is that the "page list" here is in e-book or in print version?

AvneeshSingh: do you know why it is important? for epub api - for dedicated reading systems. Some epubs transformed into web content

<Jem> bookshare is a good use case

CharlesL: I can see that actually as the author exposed the pagelist - I can see that use case

jcraig: separate subrole then

jcraig: I put pagebreak as important

jcraig: epub reader reinterprets that

AvneeshSingh: there are readers that just expose the pagelist

CharlesL: dedication we have publishers that have a dedication make where "this page is dedicated to" at the bottom not the top

chlane: example - like code examples etc... to know in an example might be helpful

Matt_King: want to ask about these group/region roles

Matt_King: those exposed as some other aria thing - i'm imagining eg chapter just becomes its own thing but part doesn't and is a group/region

Matt_King: then if using VO to read a web view i don't know how i will understand what is micro/macro navigation.. a part can be a big thing.,... if we mix concepts then as a user i don't know how to keep this straight in my head

Matt_King: the other thing (happens a lot) can't tell the difference betweeen the content and the meta info. favourite JAWS feature is where links can be spoken in a different voice... every heading level has its own voice and links have their own voice.... super common interactions

Matt_King: If the content of the link is "4" get "link 4 bibliography reference"

jcraig: Is "link 4" more clear (Matt answered yes)

Matt_King: could benefit from knowing where it is going but how announced is really important

Matt_King: in all these decisions need to be important to imagine as the user who knows nothing about it and hear all these words - can be overwhelming

Matt_King: how going to hear and what will mea

NeilS: curious as to omission of ToC

NeilS: seems like it would be useful

jcraig: was in 1st proposal

<Zakim> jcraig, you wanted to quote a colleague

<jcraig> Quoting a colleague: Roles and subroles should be added for new structural or functional elements but never for content specific purpose. To me a "dedication", for instance, refers to the content, not to the structure or the functioning of an element. Thus it should not be a role or subrole. The same applies to many of the ePub stuff we are talking about.

<Jem> +1 above comment.

<jcraig> quoting continued: As a user, I don't want to hear that kind of info either, because it is either redundant or irrelevant. The cliche "less is more" applies well here.

jcraig: 1 persons opinion

jcraig: have heard very similar from others who use day in day out

jcraig: if i'm at the start or end and there is an obiturary i will get it

sighted readers get the same info

AvneeshSingh: can work on a table as to what a screen reader can speak

I think Avneesh's point was that other implementors (chromium, gecko) have changed their mappings (due to this evangelism by DPUB members) and he doesn't want them to roll those mappings back

<Matt_King> For record would like to say that APIs should have all role information available in them, but that doesn't mean all role information needs to be spoken.

jcraig: my core concern is not the implement effort, but to retain the best experience for users of assistive technology on Apple platforms

<AvneeshSingh> The approach proposed by James Craig looks ok from high level view, unless the other API, who have already implemented all the DPUB roles do not roll it back. We can figure out the further details with Apple.

APA Working Group and Adapt Task Force Cross Meeting to discuss live regions, decorative images, and simplifying content in general

live regions

<chlane> ing [~chatzilla@11c9e7f5.public.cloak] has joined #aria

<chlane> 10:33 < cyns> subtopic: live regions [10:34] [chlane(+ix)] [2:W3C/#aria]

<chlane> [#aria]

janina: COGA and WAI-ADAPT one of the distraction points is what you might silence in live regions. Looking for ways for user agents to control the frequency of live region notifications

Matt King: Meeting such needs of users feels like an authoring consideration. Having the user agent make decisions about how things are presented

Janina: I want the user to be able to tell their user agent to do that

Matt King: That's an important decision. How do we put a requirement in our specs that we user agents to do this. Why the user agent and not the author

Janina: Authors have a lot to cover

<Jem> https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2022#ARIA_.26_APA_Joint_Meeting_2

Jamesn: We already have that in ARIA and user agents could choose to do that now. timer has a spec'd behavior. UA could already do this

Janina: COGA users won't be using A11y APIs

Jamesn: it's in the DOM too. What is missing?

Jamesn: One of the intents behind live regions is that user agents could choose to do something with it

Jamesn: aria-live off doesnt' current do anyting in UA

Jcraig: some do

Janina: Arrive-Can Android app did that

<Zakim> jcraig, you wanted to use timer example

jcraig: also using Timer as an example. VoiceOver implementation of live=off is that it only makes announcements if the timer is focused

jcraig: assertive and polite are often mis-used. When Apple implemented live regions, there were bad examples. Video player that used status and updated constantly

jcraig: there are instances of sites that are still badly coded. Voiceover has a "kill switch" for live regions. Hope we eventually make it site specfic

jcraig: these aren't things in the spec that we tell authors to do. it's implemetnation detail

matak: If we wanted to do experimentation we could make a browser extension that would take the info that's in the dom. and then we can see what people like

jcraig: and you could see what's missing and what doesn't work well. We know re-doing live-region is a big project. feedback would be good

<jcraig> cyns: also wanted to mention there are some uses to live region... some are self voicing

<jcraig> cyns: so be aware of that

bgaraventa: use cases that act differently. Timers and progress bars annoying and changing frequency makes sense. but in a live chat you don't want to limit. might be harmful if all treated the same way

bgaraventa: chatting with your bank. You've set live regions only 15 seconds. you get all the messages all together

jcraig: that's what live=off vs police vs assertive is intended for

aleventhal: also talk to Travid Leitheid at msft about new work to make announcesments from javascript

Aleventhal: they have a list of things that need fixes. these should be added

<Zakim> jcraig, you wanted to mention self voicing live regions

jamesnurthen: we have a bunch of issues on this

<Lionel_Wolberger> Confirmation of action link, https://github.com/w3ctag/design-reviews/issues/713

<aaronlev> "Confirmation of Action" aka ariaNotify being worked on by Travis Leithead from MS: https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit

jcraig: responding to cyns about self-voicing apps using live regions. I helped work on one. iWork for iCloud does this. Google Docs has done this in the past.

jcraig: no one who has built one things it's the best way

jcraig: usually there are 2 live regions, 1 for deletions and 1 for everything else. and a content-editable that moves around

<Zakim> jamesn, you wanted to react to jcraig

jcraig: building a screen reader into their app. Way more complicated than any web developer should have to do

jamesn: even apps that aren't self-voicing will have a live-region to work around bugs or gaps. Adobe does this for table selection becuase it doesn't work well in screen readers

janina: from the WAI-ADAPT perspective it's not just voicing, it's also display

janina: would like to know where to add pain points to javascript api

aleventhal: who would like to coordinate with Travis? Want to make sure they are aware of pain points since they are implementing now

janina: happy to help

johnr: I've had trouble with self-voicing apps interfering with screen reader. Shouldn't be self-voicing by default

* jem Travis is at microsoft

davidFazio: self voicing might be ok if you can turn it off. It's not just for people with screen readers. It's also for people with cognative disabilities. Research reading aloud can help

john r: no sufficient for voice app to be turned off immediately

davidF: why are we only talking about screen-readers

john r: app doesn't know which you are

<Lionel_Wolberger> +1 to keeping in mind people who benefit from "screen reading" without being users of screen readers

matatk: When we talk about self-voicing apps, we could be talking about live-regions for screen readers vs. voice api to do voice for everyone, and maybe there is a preference to be considered here.

lionel: maybe use a different word for self-voicing. People do enjoy multi-modality of reading and voice together. would be good for aria to know about it. and it's very annoying for screen reader user to have lots of extra voices

jcraig: don't think it's true that live regions are only used by screen readers. maybe other at uses it? I don't recall whether it is implemented in Switch+Speech, or Zoom+Speech, or Spoken Announcements. but the spec doesn't prevent that

<matatk> +1 to James re live regions being potentially useful to screen magnifier users

jamesn: agree others can use it if they want to

cyns: but they aren't

david: i made a learning management system that speaks

david: we need to think broader

@@@: Math is a problem with aria-live. It has some deficiencies.

decorative images

jamesn: please file issues

presentational image role

jamesn: issue has been created where people are asking for presentational image

jamesn: sometimes they are things people want and sometimes they don't. Describe images. user could choose whether to use them


jamesn: has a bunch of people with different skin tones, one with a guide dog, one with cane

jamesn: Needs better description

jamesn: I've seen a bunch of presentations with this as background. don't want it described on every slide. But, if you have one slide shared, it might be important. User preference at that time should be taken into account

jamesn: there are probably users who for cognitive reasons might not want that image. user preference how much to show

jamesn: should you be able to simplify? for example sponsors

jamesn: less importatn images that can be configured by user

janina: we thought we were ready for CR with 6 attributes, but there was a TAG issue that fell through the cracks. We're not moving to CR. TAG wants more documentation about how the attributes meet COGA requirements

janina: We are rethinking how to move forward the parts that TAG thought was ready. AAC symbols will probably come out first. We've had some good discussions during the conference

janina: simplification needs to be more detailed. one persons simplfication might be another persons obfuscation

janina: Good info first time on the page, but not every time

janina: will be a bit before it ends up in a spec

john r: like the idea of reducing cognitive load. But also consider contextually relevant images. Another use case is having symbols appear above words in sentences. That could be togglable by the user. We should consider this use case

jamesn: don't want a role. I think it should be an attribute on image. should be in ADAPT

matatk: We have a use case about symbols. I have a demo of what ADAPT can do

<matatk> file:///Users/mtatpg/projects/distracting-sign-up-form/distracting-sign-up-form.html

<scotto> hey, i remember 1999

matatk: demo has a timer, and animated gif, marquee becomes just text. prefers reduced motion turns off animate gif

matatk: ADAPT can turn off the other things

use case is for people who would not be able to cope with anything other than this on the page

david: attention is one of the biggest things for exhaustion. movement is a big problme

<Zakim> jcraig, you wanted to mention spatial navigation importance of arguably presentational images

jcraig: internal apple example. Tips app on iPhones (not web). Is this image important? It's one giant image with a little text at the bottom. some content people said it just shows the mood and not really that important

jcraig: Spacial impact of interface. It was a big graphic. Able to touch in the screen and know what's there, even though it's decorative

cyns: people disagree about what is the important content, for example, ad servers

cyns: sounds difficult to categorize how important things are different for different users and content servers

cyns: like images on pages, at a previous job we were trying to provide an idea of a diversity of tasks?? how to communicate with alt?

<Zakim> Judy, you wanted to clarify my understanding of the TAG's misunderstanding, unless those have been overtaken by events since the joint meeting

cyns: also consider needs of site owners. Ads or sponsors may be important

judy: TAG marked the issue as closed. communication issue.

judy: at least for due-dillience, we should get clarified assessment with TAG in APA

judy: if it turns out that it's not good, then that's one thing. But let's make sure we're not losing it due to miscommunications

janina: Let's figure out a path forward

lionel: co-chair of ADAPT spec. Some new thoughts from this TPAC. media-queries represent hard decisions made by site owners about what is important

lionel: Group is open to rethinking, in general, how presentation images should be handled. "mood" images are sometimes removed on smaller screens

<Zakim> jcraig, you wanted to discuss based on role, required field, etc

lionel: Blind people have tone and pitch awareness. APA looking at modifying pitch, voice, etc.

jcraig: Safari reader has some logic to remove distracting things.

jcraig: in the example, there are required fields that are usually marked up. There can be a "critical" or "moderate" view. Can be done as an extension or grease monkey script

matatk: ADAPT is using extensions.

matatk: could be an authoring tool

jcraig: we're not going to do presentational images, but will work with APA on use cases for adapt

hi everyone please join our meeting once again?

<yonet> agendum: https://github.com/immersive-web/model-element/issues/39

marcus: apple has proposed a new element for html, a model element

marcus: it allows developers to put in place a three dimensional potential interactive animated graphic

marcus: there are accessibility challenges. it doesn't have a dom -- it may in the future

marcus: it would be good to know what the accessibility requirements are, and get them right from the beginning

marcus: it can also be used in VR space

marcus: same model both places

marcus: apple has been working on accessibility in VR space

marcos: is anyone interested in collabing with us long term?

marcos: the elements can be tactile ???

marcos: we want to go beyond an alt attribute for these things

cyns: there is some overlap with accessibility 2d canvas

cyns: we should gather your use cases

cyns: we tried to have an accessibility object model for that, and there were some early concerns, so we are going back to use cases

cyns: and I am working on that would love your input to find overlap

marcos: if we don't need to layer it like AOM

marcos: we need to have this discussion with kronos group, apples format

cyns: aom is one solution for some problems, maybe not the right solution for all problems

jamesn: clarifying question: we talking about an object or the three space?

marcos: everything is up for discussion

marcos: it's a view port, a cut out into 3d space

marcos: that you can interact with

marcos: not virtual reality

marcos: you can even make your company logo with it, and the logo can be moved around a little bit

marcos: you can use it as decoration, or in educational spaces, or product pages (showing products)

marcos: what is the point of focus?

Brandel: apple has a proposed implementation present in safari behind a flag

Brandel: the models are being displayed inline in the context of the page

Brandel: we have controls for animation to play or pause or skip to peice of animation, and to tumble it

Brandel: this could be a reference implementation

jamesn: what specific things do you want from ARIA?

marcosc: mostly I'd like to make you aware this work is starting, we have significant industry interest it seems

jamesn: is there any adobe people involved?

marcosc: I don't think so

<Jem> Boaz came to ARIA APG meeting about geospace accessibility topic a month ago. I am wondering whether this is relevant to the dicussion we had.

cyns: this has similarity to 2d canvas is that it is rendered but doesn't have an object model

cyns: like how do you handle space that is bigger than the dom/viewport

marcosc: an example is that you start at street level, but zoom out to a whole city

cyns: one use case, if you don't have the whole dom, how do you get to the heading on page 200

cyns: also how do you find things that are there, activate the things, drill into things, without 2million dom nodes around

cyns: text editing is an example of things, editing of shapes

cyns: adding objectings/removing objects?

marcosc: editing is not something we are thinking about right now actually

Matt_King: you started the convo with a question about collaborating, it seems to me like the most important thing we can do is talk about the process for how we would work together

Matt_King: one of the most important things for us to discuss early on is what are the requirements -- process requirements -- for getting accessibility right the first time

Matt_King: Aria is having process discussions yesterday and today, we are revisitng

<cyns> draft doc to gather use cases (name is tentative) https://docs.google.com/document/d/1r9csj_b_u9s_8n09X2jao1QjJpPDBmRfJ05NWVOgjF0/edit?usp=sharing

<Jem> From Scott Vinkle's blog post, I see these aria info.

<Jem> WAI-ARIA Roles, States, and Properties

<Jem> The 3D Model has role application.

<Jem> The 3D Model has the aria-roledescription property set to 3D model.

<Jem> The 3D Model has the aria-label property set to provide an accessible name.

<Jem> Optionally, the aria-describedby property is set on the 3D Model to indicate how to interact with the component.

<Jem> The Live Announcement element has role status.

<Jem> The Full Screen control has an aria-pressed state. When the button is toggled on, the value of this state is true, and when toggled off, the state is false.

Matt_King this is a place to create new paradigms, but we need an appropriate level of research to do it correct. there is so much research not related to accessibility in this space... to think we could get accessibility right without a robust exploratory program, with real people, that takes up a lot of time

Matt_King: we can't really just paste our existing paradigms into this whole new world

Matt_King: if there is an implementation available in safari, we should start that research

Matt_King: if that research can be out in the open (which might be hard for apple) then we can have a real discussion about it

Matt_King: we can make architectural decisions based on research results -- but we need community collaboration and input on that process

Matt_King: I think we need user experience and research institution level to answer cyns question

bajones: we are looking to accessibility canvas... we have 2d model tag up coming.. we have webxr API based on canvas protocols and webgl specifical

bajones: almost entirely inaccessible

<yonet> What we are talking about as model-element specificly is very similar to google model-viewer linked here: https://modelviewer.dev/

bajones: ???

bajones: how far along is the canvas work?

cyns: some former googlers have code behind a flag that makes a tree of accessible objects added to the dom

cyns: but there is privacy concern so it hasn't moved forward

cyns: when moving from dos to windows, a 2d graphic world, added a whole new API, we don't have pixel based web apps

cyns: because it was assumed the web would have a dom

cyns: there was official story for accessible in canvas, but it didn't work out - no one used it

cyns: svg is sort of like that, mapping for every object, but it is heavy

bajones: please share any resources

bajones: so we can keep in sync

cyns: I put links above and I'm happy to meet

marcosc: I want to follow up on Matt_King and cyns -- about cyns, we have some experience, Matt_King said we have tried various approaches -- hopefully there are some ideas about what works and what doesn

marcosc: at the same time, from the apple side, we have been doing this work for a few years, we invested heavily on the a11y side with real research

marcosc: at the same time we are constrained across all operating systems and the different accessibility APIs

marcosc: microsoft probably has feedback

marcosc: and VR has been around since the 80s, lot of research since then

marcosc: and it is expanding

marcosc: I think we are in a good place to make good tech decisions, the research is there we need to bring it together

Brandel: as a proposal, our model is an attempt to describe the minimum useful features for anyone to use

Brandel: later down the line to add other interaction modalities

Brandel: for example, editing is not possible in our initial thing

Brandel: would like to know, what are the simple must haves

Brandel: and where are hidden complexities

Matt_King: I'm not aware of relevant research ... like if we make technical decisions about what are the minimum requirements, these decisions are can't be made without understanding how the content information will be presented to users, or if it satisfies the needs of users, how can we do any of that without the prototype and exploration of those protoypes with users?

Matt_King: like describing 3d content to a blind user? there has been research on that?

Matt_King: seems like we should be talking about a spec development process that involves checking our selves along the way in the development of accessibility apis historically - -we guess as the needs, building something, let people use it and find out whats difficult, then add bandaids

Matt_King: this is way more complicated than anything we have ever done

Matt_King: so with trepidation, I say, it's going to take some thought and work

<yonet> XRAccess is a great source for some of the research going on: https://xraccess.org/research/

marcosc: exactly to your point, we have made the model implementation already available behind a flag FOR people to explore

marcosc: we have a degree of confidence in what we are doing, but I agree, this is tremendously useful

marcosc: we have an inaccessible prototype, so lets figure it out how to make this model accessible

bkardell_: I have a lot of difference comments. one, specific feedback, you mentioned research, can you put links in the explainer? people coming in looking at explainer would like to know right away where did this come from?

bkardell_: also a question: you said it's completely inaccessible? I thought description was supported

marcosc: it's an html element so anything can be put on the html element

bkardell_: last thing, I'm very interested in accessibility of the canvas and AOM and immersive web I would like to keep working on this issue in particular

yonet: what can we give you to get your help?

jamesn: seems like it fits a bit more in the AOM

jcraig: maybe a wicg spin off

jcraig: wicg

<cyns_> Where canvas a11y gets discussed https://github.com/WICG/aom

bajones: the people who want to participate from accessibility and immersive web-- the overlap is close to a circle

bajones: don't we have a repo for accessibility in the immersive web.. or a document...

Matt_King: but people who want to responded to accessibility questions would be overwhelmed by everything else -- so maybe a seperate repo would be better, just to organize work

Matt_King: someplace we need things like accessibility road map and plan and structured approach, a "label" is kind of too understructured

<ada> https://xraccess.org

ada: it's not a w3c group. but here is a other group ^

ada: they do a lot of xr accessibility research

ada: some experiments with web xr

cyns_: maybe adding that to an explainer with high level road maps

jamesn: lets have a check in meeting in a few months time? we can com eback in a couple of months

bajones: agree

bajones: we want these topics in immersive web more often... we should probably make a solution that doesn't just work for webxr


sarah_h and scott created a new doc

<sarah_h> https://docs.google.com/document/d/12mYmK0_qkAMERntVFqqWYwLw2hseGGzZKbRYZ9M37Yo/edit

style optiions icons images

it should play that role on the way

degree of customizability

content model within


things like that

state now

select menu permissive on purpose

it wont kick random button out

browser console warnings occur

secondary actions proposal

2 sections


actions make them accessible, allow things in between option

keep it permissive

to make things ..

goal is to be a11y by default

with intended default usage

like correclty using <select>

icons within options

extra divs generics

without issues

intersting, put a button between options.in theory a table

between options

MattK back up a little

comparing <select> and openui selectmenu


new element <selectmenu>

like <select> 2.0


fix all complaints

about styling

and cant fit random stuff

explainer has examples

that are visual

jamesn: theres a demo page

aaronlev: can you have a text field to filter?

sarah_h: not an autocomplete

one use case

text input in popup

woild trigger console warning


cyns: can make combobox with select element

sarah_h: the trigger is still a button

content model is more permissive

in <seletmenu>

cyns: color dialog

conceptually picking from a set

mattk it could render as a dialog

sarah_h: if author were to insert misc interactive content

would require semantica and keyboard changes

selectmenu will not support that

wont prevent

console warnings

<selectdialog> ship soon as a goal

<cyns> https://open-ui.org/prototypes/selectmenu

Matt_King: wary of magic in either case, in css toggle or here

cyns: some devs do all some dont

cyns: what would happen in a11y tree?

sarah_h: it would show up

menu item menu item buttom

option option button option

mattk listbox has always had option

cyns: listitem

sarah_h: arrowing moves through options

tabbing selects and closes

if button in there it is undefined behavior

sarah_h: how much should browsers repair?

button is the simplest example

if someone inserts a textarea or tree in there

mattk how can you have the error?

console errors

don't do that this is not a11y

for a combination of tech reasons

mason F would be able to do that

cyns: trying to avoid xml yellow screen of death

sarah_h: hard to get changes approved

sarah_h: techical, political up in the air we may want to allow it for certain content

before or after but not interspersed

kicking everything out would preclude that

aaronlev: mason said we would go back to divs

<Zakim> jamesn, you wanted to say that presumably a11y checking tools can error this too

cyns: strict parsing is why xml didn't get picked up for the web

jamesn: checkers can error on this too


aaronlev: if anything is disallowed, it will lead people back to using divs, and we get way more accessibility when people don't use divs

cyns: console error

chrome has built in

sarah_h: implemented in chromium

go the next thing after

sarah_h: labelling options

current there is a label atttribute

not styleable

icons images extra spans not possibel

repurpose legend element is the plan

mattk permissive doesnt' work so console errors occur

will the spec still say something normative?

other things doing the non permissive content model

jamesn: it will work right with mouse users

cyns: layout would be weird

mattk make it intentionally bad, they are going to go to divs

jamesn: quickly move to the thing that does everything

sarah_h: keep people from using divs

best plan

jamesn: how does it relate to popup?

internals are intended to use as the <selectmenu> popup

jamesn: until <selectdialog>

sarah_h: no element to recreate the group of options

talked about but resolution to not hold up selectmenu

greater demand

cyns: checkboxes more common way to achieve that goal

sarah_h: raise as option, using menu semantics instead of listbox option semantics

mixing checkbox with menuitemradiobutton is possible

Mattk way to go just because of the options

matt k makes sense

cyns: looks like menus

sarah_h: personal exp, menus have better screen reader usability

mattk one of the things about menu... may or may not be different

when it opens and you activate a radio

it is temporal and immediately closes, is that what you imagine

sarah_h: yeah, space does not always select seems like a good idea

mattk specifically a single select

cyns: navigate onchange

hit enter and go to other page

sarah_h: it has on onchange

mattk open a drop down, down arrow, triggers onchange, prevents you from navigating to other menu options

jamesn: don't care either way

ok with select menu for changing a value

if it works better

if for selectmenu

why not do the same for select?

cyns: list not a menu

mattk have to look at html aam

mattk don't know select is differentiated in terms of single multi

jamesn: select mutliple maps to listbox

no multiple to combobox

cyns: like that menu is separate from listbox

mattk we have a select only combobox

this is a better way

mattk, curious about value

janky way of getting value from content

sarah_h: good point but different then aria combobox

this is an actual browser element

mattk that is what we do in ARIA

cyns: does a form post

<Zakim> jamesn, you wanted to say I din't expect such easy agreement on menu

sarah_h: everthying is customisable, slot for any html

it is not guaranteed to be a string

extra way to get a string

cyns: name from shadowdom problem

mattk have select instead of just showing words you want to show an img of the selected item

divs and spans all styled

wouldn't we just want

soemthing like accname calc

cyns: difficult to implemement

jamesn: simplified accname

sarah_h: value attribute on options

jamesn: thats not user displayed

cyns: example with value attributes?

mattk get these examples into experimental pages in the AP


<cyns> cyns: an example of a form post with a selectmenu

if we follow a process like that

jamesn: apgalpha

sarah_h: useful for popup, toggles

mattk other variations

mattk depends on browser mapping

matt turn on a flag in a browser

instructions for examples

bryanG menu related, put anything in menu?

sarah_h: not supposed to but you can

bryan API, menu open, close,

button activated, rendered menu

same construct with menu and menuitem roles

wouldnt work in voiceover

told them to change back to combobox role and it worked

jaws,if you tab into a menu hard to get out

can get out of the listbox

mattk have to talk to vispero in the ARiA AT project

menu and menuitiem i assumed the openui select menu opens a menu

the button isn't really a button

its an element with a name and a value

sarah_h: popup would have menu semantics

matt we don't currenlty wrap in ARIA

bryan g be careful

to APG

hide behind a toggle

sarah_h: not an issue, it wont be used if it is not functional

jamesn: it shouldnt be available





<jcraig> jongund hi!

<cyns> AX API Property: AXValidationError: textual content of the referenced element

ISSUE: https://github.com/w3c/aria/issues/1440

<trackbot> Created ISSUE-1057 - Https://github.com/w3c/aria/issues/1440. Please complete additional details at <https://www.w3.org/WAI/ARIA/track/issues/1057/edit>.

sarah_h: secondary actions refer to actions that are indirectly related in a composite widget, like a close button in tabs

Secondary Actions

sarah_h: say you have a tree of emails, and each email can be activated, but there are additional buttons to flag, mark as read, delete - those are all secondary actions to the email

sarah_h: or mute buttons on chats, there are other cases where you can download or share or star

sarah_h: the issue is that you can't nest interactive elements like buttons, etc in many of those patterns.

sarah_h: even if you try, they are not exposed semantically - there are no exposed hints that there are additional activabtle things, etc

sarah_h: so the proposal is aria-actions - it would take a space separated list of ids, similar to some other aria attributes

sarah_h: it would point to the list of the associated actions - share, star, etc

<sarah_h> https://github.com/w3c/aria/issues/1440#issuecomment-1091984559

<sarah_h> Add specific aria-actions attribute with the following requirements: aria-actions is allowed on all nameable roles aria-actions may reference any element with a widget role, excluding the container roles of composite widgets (e.g. it could reference a menuitem, but not a menu) Authoring requirements for aria-actions: The controls referenced by aria-actions MUST exist in the DOM Authors MUST provide a keyboard mechanism to navig[CUT]

sarah_h: the associated actions just need to be idref based links - they must exist... the idea is that we expose this so that screen readers can say somthing like "3 additional associated actions". Proposal is that aria would only specify that thse should be exposed and that AT must provide a way to navigate those, not how

sarah_h: prosal says it may be used on any nameable role. the authoring requirements MUST exist in the DOM, authors must provide a keyboard mechanism to navigate to them, it must be discoverable -- (it is written in better detail in the issue) - there is also something in there about how it affects accessible name

sarah_h: there is also a change to children presentational so that those children can still be exposed even in presentational=true

sarah_h: I've talked to reps at jaws and narrator - they seem positive/on board

jcraig: this is a great idea. I love it. you are brilliant.

jcraig: A couple of things... I'd asked about the heuristic detection... I'll come back to it... the other question was about accessible name

jcraig: everytime someone suggest a change to accname, everyone says "oh no this is so complicated"

(some discussion, yes.... it's complicated)

sarah_h: the elements with the reference must exist in the dom... you could add aria actions only when it is focused or hovered, or you could change opacity or visibility on hover or focus

<Zakim> jcraig, you wanted to ask about the accname suggestion

jcraig: So they need to exist and be visibile and unobsured

sarah_h: they just have to exist

jcraig: should we say it is an error if they are not visible or obscured?

jcraig: it would be pretty clear it is not a mouse user

sarah_h: is that functionally different than things that have opactity 0 today? I don't think aria actions is different

jcraig: you're right there are a number of ways to detect doesn't negate the need for us to be cautious about expanding the number of ways we can do that

jcraig: this is specifically called from specifically AT - if they are never rendered only AT will hit them

jamesn: I thought that part of this was that they would be and keyboard users too would activate them

jcraig: it almost seems like if there is an action available we could do some mouse hit testing and make sure that it seems offscreen we don't expose it

jamesn: there does seem like there is AT work to ensure

jcraig: we should maybe say something about this in the spec to say if it is not visible it shouldn't be vixsible

Matt_King: AT doesn't move the focus and we can't require focus

sarah_h: but if someone has this set up to not move focus with the cursor - but then they move their cursor and the menu does not show up, they probably still want to delete it

Matt_King: I don't want to have to change my settings to use a website

jcraig: I am worried that the same pattern could be used by a malicious actor

Matt_King: I don't think that we can... that's more like a fundamental thing... I don't think we should prevent what is just another flavor of the exact same path that already exists

jamesn: we should try to distinguish between things that require user actions to detect and those that do not

jcraig: the way I think about it is: find out where the element would be rendered - if it is just opactity, the browser could do something here to include that and try to make sure that it's probably a good intent

sarah_h: with secondary actions it can be added to for example rotor... On their own UI... but aria itself is just saying the author should provide a way to get there - it doesnt give you all of the ways to get there..

jcraig: we can simulate events on any of this - what I am trying to avoid is privacy cg coming back to us on this

jamesn: completely preventing may be impossible, but we can do our best

jamesn: there are easier ways than this

<Zakim> Matt, you wanted to react to Matt_King

<jamesn> #1805

<Github> https://github.com/w3c/aria/pull/1805 : Draft: aria-actions addition to the ARIA spec

Matt_King: I guess I am a little bit leary -- I mean I love this, btw - but I am a little bit leary by its scope... I do think we need to look at some of the scope... putting this on any nameable state might create lots of issues related to keyboard accessibility

Matt_King: aria key shortcuts doesn't have full support - at least on the first pass of this, I don't think it tells you about what the actions are... If your screen reader lets you see it, good... If you can see it, good - but if you are a keyboard user and can't see it - that is a problem... Requiring that you can get to it seems important

BGaraventa: Say you have an element that has aria actions on it - how is that discoverable by the user

sarah_h: It is attached to the element with the primary actions, so this would require updates to AT to let you know that there are secondary actions associated with it

Matt_King: if it is on any nameable element - a slider, a spinner, lot of things are nameable - I'm having a difficult time thinking about a slider on iOS that has 3 associated actions.... well, no... actually, maybe that would work ok

<Zakim> jcraig, you wanted to reaffirm I love the proposal and am not opposed. I just want to make sure we make the privacy aspects as solid as possible and to explore the submenu proposal (maybe from Alice?)... actions show up as a triggerable menu item

Matt_King: after thinking outloud for a second - maybe for voiceover that isn't a problem. I am struggling still a little bit with how we could come up with common keyboard conventions. It's good from an aria perspective that we aren't going to put all of the keyboard requirements in the spec, but I don't think we can put it into the spec without some careful thought about practices and how this would apply to any kind of element that allows


jcraig: At least in most of the apple AT, I dont think we have to really change anything at all. When webkit receives the action it can simulate the thing underneath

jcraig: I also want to confirm that I love the propsal, I know I'm sounding a little harsh - I do have the privacy concerns

jcraig: I think there was a proposal, maybe from alice that this would maybe be useful as a mainstream attribute.. that would allow us to avoid that, perhaps because it would be indistinguishable

Matt_King: a huge advantage to that is that UAs could potentially solve that keyboard interaction.. not fully, because as sarah_h pointed out, sighted users expect that if they can see the button, users expect they can get to it - but as part of a context menu mabe they don't

sarah_h: it's come up in openui too - having something like context menu support would be ideal in my view. is it not viable to have aria affect the context menu

everyone seems to agree yeah, that's not going to happen

but that it could be something else

sarah_h: you mentioned that you wanted to say it would be good it is was directly keyboard accessible -- I was thinking of tabs or anything with file tabs - users don't want to tab through all of the close button.. that's a well known case where a common key shortcut is useful

<cyns_> cyns: It doesn't have to be a grey context menu. It could be a different UI that is defined by the browser. As long as it's an html element and activating the UI synthesizes a click

Matt_King: I can see why browsers did what they did but I find it less than ideal sometimes

Matt_King: So what you are saying is that there are cases where there are useful and common things to do where you don't want it to be focusable

<Zakim> bkardell_, you wanted to react to cyns_

<jamesn> bkardell_: are these more other keys? don't want the secondary actions to all be focusable?

bkardell_: (asks a silly question)

cyns_: this is very similar to the question yesterday about f6 loops... we define how that works in the authoring guide, but it does seem like html needs more kb access

cyns_: Not as an assitive tech thing, as just a general use thing

<Zakim> jcraig, you wanted to mention arrow active descendent style kb access

jcraig: (sorry I missed it scribing)

<Zakim> jamesn, you wanted to say that someone should do something about that

cyns_: Different layers of keyboard integration.. while some of the humans in this room might be involved in sorting that out - it is not aria's job

jcraig: every single time we have allowed web ui to show somethin gin the native ui, bad actors use it

Matt_King: I'm still a little bit uncomfortable - I get the use cases, but there is something that makes me uncomfortable about the complexity... What you are describing cyns_ makes me maybe even more uncomfortable... It does feel to me like we need to think very carefully about the keyboard patterns in a wide variety of use cases and document what you should do and how it should work... I think the main question now is do we do this in aria

or out of aria

sarah_h: I do think that doing it in aria is kind of prereq to moving it to HTML or OpenUI... we need to update the AT, accname - some general things that make it possible to do those things... people who are building things in openui lack these fundamentals

Matt_King: we should probably map or document that as a roadmap

cyns_: I do worry that you will get blocked in the same ways doing it in aria

cyns_: first*

jamesn: can we do it in openui?

(crosstalk, missed it)

ARIA process

<sarah_h> https://docs.google.com/document/d/14dOVzG-nB1P-uLBET3BYC2v_LvfPpUPWvRfqGLUnBzg/edit

<CurtBellew> Have to run. Bye, all

<chlane> Also have to leave thanks everyone

<jcraig> thank you both for joining!

<MichaelC> https://www.w3.org/WAI/ARIA/workflow

<Adam_Page> Have been listening quietly all day and am about to lose my internet for the remainder. Thank you everyone for the warm welcome and the very exciting discussions. Looking forward to getting more involved! Safe travels home for everyone.

<Zakim> jamesn, you wanted to react to jcraig

<Zakim> jamesn, you wanted to react to matt

Summary of issues

  1. https://github.com/w3c/aria/issues/1440
Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).


Succeeded: s/jamesn/Jamesc/

Succeeded: s/jcraig: something we have to check/gpel: something we have to check/

Succeeded: s/gpel:/gpellegrino:/

Succeeded: s/"link 4" is much clearer/Is "link 4" more clear (Matt answered yes)/

Succeeded: s/other implementors have done this so long as they don't roll it back/I think Avneesh's point was that other implementors (chromium, gecko) have changed their mappings (due to this evangelism by DPUB members) and he doesn't want them to roll those mappings back/

Succeeded: s/my core concern is to keep best experience to users/my core concern is not the implement effort, but to retain the best experience for users of assistive technology on Apple platforms/

Succeeded: s/be aware of that/cyns: so be aware of that/

Succeeded: s/live=off is intended for/live=off vs police vs assertive is intended for/

Succeeded: s/anyone should have to do/any web developer should have to do/

Succeeded: s/voice for everyone/voice for everyone, and maybe there is a preference to be considered here./

Succeeded: s/live regions being/live regions being potentially/

Succeeded: s/I don't know if that's implemented./I don't recall whether it is implemented in Switch+Speech, or Zoom+Speech, or Spoken Announcements./

Succeeded: s/aira/ARIA/

Succeeded: s/ycg/wicg/

Succeeded: s/scribe//

Succeeded: s/mattk like magic in css toggle not conflate/Matt_King: wary of magic in either case, in css toggle or here

Succeeded: s/everythign/everything/

Succeeded: s/ok with it/ok with select menu/

Succeeded: s/valu/value/

Maybe present: @@@, aaronlev, aleventhal, bajones, Brandel, cyns_, david, davidF, doc-subtitle, Jamesc, jamesnurthen, jcraig, johnr, lionel, marcos, marcus, matak, sarah_h