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://
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
#1643
<Jem> https://
<Github> https://
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://
Matt_King: what is your overall objective
<spectranaut_> jcraig reference the original prioritization of roles from DPUB is listed in this comment: https://
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
1+
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-chapter
doc-pullquote
doc-subtitle: Is this sufficiently different from heading? [Update: @scottaohara says yes, would help with https://
doc-footnote
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)
doc-dedication
doc-example
jcraig: Charles mentioned okay to skip, but above Avneesh ranked these higher.
doc-pagelist
<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://
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://
<aaronlev> "Confirmation of Action" aka ariaNotify being worked on by Travis Leithead from MS: https://
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
https://
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:///
<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://
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://
<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://
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://
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://
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://
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
selectmenu
sarah_h and scott created a new doc
<sarah_h> https://
style optiions icons images
it should play that role on the way
degree of customizability
content model within
options
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
buttons
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
qv
new element <selectmenu>
like <select> 2.0
styleable
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
https://
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://
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
easily
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
G
<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
https://
1.3
https://
https://
<jcraig> jongund hi!
<cyns> AX API Property: AXValidationError: textual content of the referenced element
ISSUE: https://
<trackbot> Created ISSUE-1057 - Https://
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://
<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://
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
this
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://
<CurtBellew> Have to run. Bye, all
<chlane> Also have to leave thanks everyone
<jcraig> thank you both for joining!
<MichaelC> https://
<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