Meeting minutes
relational terms
<jamesn> w3c/
spectranaut_: this session is because I was confused so I want to go over some changes we could make
spectranaut_: required owned element and required context role have been removed (renamed?)
spectranaut_: second reason is to clarify some relationships (see google doc)
spectranaut_: define "scope"
spectranaut_: will review the terms that exist in the spec
spectranaut_: 1st 2 terms are "accessibility child" and "accessibility parent"
matt_king: some accessibility trees include the accessibility child right
Matt_King: you're saying that in the spec we should be able to use the accessibility child and parent without the modifier key?
jcraIg: i suggest we keep it in there to avoid confusion
sarah_higley: "child" is used without accessibility when used the second time in the same sentence
jcraig: this type of decision should be in editors style guide
spectranaut_: one example we could pull up where child is used is...
sarah_higley: (reads 5.2.6 Allowed Accessibility Child Roles)
Matt_King: if you're defining the requirement of a role I can imagine other context where we're talking about scoping of a state or property and, when we're talking about what the browser is going to do instead of what the authors is going to do, I think it should always be specified
spectranaut_: you're talking about anytime we're talking about the computed accessibility tree?
Matt_King: yes
Matt_King: we need to be careful about the language there
spectranaut_: I'm not sure the language is clear enough to differentiate when we're talking about the computed accessibility tree by the browser vs. when the tree created by authors
Cynthia: accessibility child I had always assumed meant that it always was talking about the accessibility API
spectranaut_: need to review the spec language that talk about the computed accessibility tree?
jamesn: I don't think we do it a lot
Cynthia: I think platform a11y API when I hear "accessibility child"
sarah_higley: it is different than the DOM child
sarah_higley: accessility child != DOM child because a couple of extra properties are exposed (missed that part)
jcraig: I think it's a good term. Specifically defined for the ARIA spec, not for outside of the ARIA sepc
s\sepc\spec
jcraig: we went back in forth for at least a year on this
jcraig: lots of feedback in this PR
jcraig: editorial note: have we defined the term "intervening"?
jamesn: if we use a term we can define it inline
spectranaut_: it's used at multiple places
spectranaut_: do you think a11y child/parent should have been defined in "required"?
jamesn: we used to have "terms" for all the important terms... the goal now is to have an inline definition instead of a large section
jamesn: against defining intervening
cyns: is the plan to not have a glossary?
jamesn: yes
ackme
<Zakim> BenBeaudry, you wanted to react to jcraig
spectranaut_: let's revisit the term "intervening"
spectranaut_: I understand now why jcraig believes this definition should belong in the spec
jamesn: if we export these terms they become normative. This means that other specs could reference these definitions and reuse these terms
spectranaut_: owning element never used, so let's just get rid of it
spectranaut_: owned element has a good and a bad example (see google docs)
Everybody appears to be onboard to get rid of the "owned" term and replace by "descendant"
spectranaut_: "context" there's no definition and it doesn't mean much. It's confusing and people extrapolate from other definitions
jamesn: I'd like to suggest that we have all of those definitions validated and verified by someone who really knows the ShadowDOM
cyns: let's table this until 1 PM we have folks from AOM who know this
Adam_Page: I read accessibility child as being "one or many of those things"
Need to be explicit that it can be one and only one
<jamesn> qv
Matt_King: we need to think about the inverse of this
<jamesn> ?
cyns: when talking about all of these relationships: "what's the terminology we should be using to communicate the different relationships"?
jcraig: we're using a11y child to differentiate between DOM child
cyns: should we add a note at least?
everybody agrees
spectranaut_: we're at time
spectranaut_: since no one seems to be against, we'll get rid of the term owned
Host Language Computed Role, Extension Spec Computed Role
jcraig: WPT tests can now get computedRoles
… left as an implementation detail
… concrete core-aam roles - examples of <button> -> button, input[type=range] -> slider
spectranaut_: the fact that it is an implementation details is maybe unclear to most folks
spectranaut_: the roles that are used in the a11y are not specified
Matt_King: what you see in chrome a11y tools are those the computed roles and (until now) they haven't been specified
jcraig: when there is an obvious aria role we return that. but in 1 scenario what webkit says is no specific aria role - asked webkit folks should we return soemthing that exposes implementation details
jcraig: <video> -> ???
jcraig: video comes along with different client side APis (pause etc) the media control keys pass through to it whatever the author has done wrt to buttons. We can't support that with ARIA. Didn't want a video role which doesm
n't support much
jcraig: <iframe>, <mfrac>, <rt> all don't have an aria mapping
jcraig: in SVG-AAM <circle> -> ???
jcraig: Webkit: image , Chromium: graphics-symbol
jcraig: primary goal of making these match is testability
Matt_King: is there a way to do some sort of namespacing
BenBeaudry: where does image come from?
jcraig: will get back to that
jcraig: DPUB-AAM role="doc-toc" -> ???
Webkit: navigation (concrete superclass of doc-toc), Chromium: doc-toc
jcraig: explains how svg-aam has platform mappings on graphics-symbol, the graphics-aria defines that graphcis-symbol has a superclass of iimage
jcraig: proposing that the computed roles would be html-video, html-iframe, mathml-mfrac
jcraig: ruby-rt
1.2 role parity was intended to solve this
jcraig:
jcraig: treat them like abstract roles
jcraig: a bunch of examples
jcraig: make proposed changes or some variant.
jcraig: benefit testability, disadvantage short term implementatoon change
jcraig: or do nothing so lose the benefits
spectranaut_: 2 options: feel like whatever is easiest for implementations is what we should do
jcraig: single role easier but not significant difference
<Zakim> Matt_King, you wanted to ask about impact on screen readers
Matt_King: where do all these things get defined
jcraig: in each of the host AAMs
Matt_King: we don't have to define the role of html-video anywhere
Matt_King: if this is the computed role - if you were to make changes to what is happening right now. if change svg-polygon to graphic.
jcraig: this should never leave the browser
jamesn: suggests that dev tools should show that folks shouldn't use this computed role
scott: want to solidify the minimum role concept
scott: style element is not mapped but if one were to display:block it and put contenteditable then now we need to expose something
<jcraig> https://
<jcraig> https://
<BenBeaudry> github: BenBeaudry
<andrea_cardona> andreancardona
<sarah_higley> gh handle: @smhigley
<dmontalvo-mac> daniel-montalvo
<Adam_Page> GitHub username: @adampage
<aaronlev> BenBeaudry: did you find the accname WPT tests in the chromium source tree? I don't see them
<BenBeaudry> aaronlev: I haven't looked.
AOM
nolan: slides on cross root ARIA
nolan: you have to ask for permission to view slides but I will give you permission
nolan: (describeds cross root aria from the slides)
<jamesn> link to slides: https://
<alice> https://
aaronlev: (didn't catch question in full) label on a custom element but it doesn't have a role... you are putting a name on prohibited element.
aaron: do you end up with two aria-labels, because you put one on the custom element and then it gets used internally
alice: its more like stealing. the shadow root says "if you put element x on the shadow host, it should act as if it is on element y in the shadow root"
aaronlev: is delegation the right word
alice: delegation is over used in this context
<aaronlev> I was tripped up by the term mirroring, which made me think it was in two places
alice: it is extra hairy in the relationship attributes.
alice: if you were to try to implement this now, if you copy the id ref down, it's not longer valid because you are in the shadowroot
alice: if you say, I have text field, adjacent to the text field is options in the listbox. the options are in the shadow dom. The items might be fetch from the server, maybe you don't want in the dom because different options at different times... but then the active descendant on the textbox is put on the listbox shadowroot instead of the options... this can get complicated because active descendant SHOULD be an option but instead it
is a lite.
aaronlev: another quick comment: with activedescendent, we use a heuristic. the focusable state is often not super important, we try to get it right... but what will happen in this case.... activedescendent only points to the shadow host... we would have to have some new heuristic
jamesn: how important is having a declarative syntax?
nolan: I would like a declarative syntax
nolan: if we have "encapsulation-preserving element reference" solves 99% of problem
nolan: but it makes accessibility an add on
nolan: from my work I think it is important, but we should unblock things more importantly
westbrook: we should at least plan for declaratively
westbrook: unless we have a plan, people are going to make a new spec, because they will want a declarative way
westbrook: should should say at least this is how it should work
<Zakim> alice, you wanted to talk about declarative syntax
alice: I think westbrook made the point well. I have had chats with brian kardell how early on with shadow dom we dropped the ball with declarative options, and now we are in this situation
alice: I think the declarative options and imperative options is always going to be a problem, for example, nolan talked about empty strings appear in the content attributes when setting them imperatively
alice: only compromise.
alice: the classic is server side rendering
alice: for needing declarative options
alice: but what are the other scenarios in which people need declarative options?
benhowell: I have been working on an implementation of semantic delegate for chromium. the issue of attribute on different element than the one it applies to has been weird to work on. problem for both cross root aria and semantic delegate. you need to name the element in the scope where it exists.
cyns: isn't the goal to be able to use xinput the same way as they use input, so it seems good that the aria-labelledby goes on it, from an authoring persepective
benhowell: from the implementation standpoint it is weird/hard
cyns: I think it seems very natural for the author
benhowell: it makes sense that your input whats to be like an input. Where do we draw the line on which attributes can be forwarded down? that is where it seems a bit hard
<aaronlev> the bottlenecking is not ideal. Why does the attribute name on the shadow host need to be the samee?
<aaronlev> data-mytextboxlabel="id" data-mylistboxlabel="id2"
nolan: I think there are cases where the weirdness does extend to the web author
nolan: for cross-root aria (gives examples... like double input... you can't aria-labelledby both) essentially it doesn't work for authors in the bottle neck situation
cyns: do the other proposals have fewer weirdnessess
nolan: I think the weirdness applies to cross root aria and semantic delegation
nolan: I think its less for encapsulation
jamie: I had this vague recollection there was another proposal that involved importing and exporting some ids
jamie: I thought that solved the bottleneck effect
nolan: I think there is an issue from 5 years ago
jamie: why was the discounted, its awk
alice: the gist I linked above
<alice> https://
alice: discuses that option
jamie: seems like a keyword type solution to the problem. this custom id is asking for some specific things you need to provide as an author
jcraig: for benhowell, for the definition of "weirdness" -- is it that it is reusing the same attribute name to mean something different. "passesthrough-arialabelledby", would that make it less weird
benhowell: a different attribute name would help the author understand that it is something slightly different. its more like this is something totally new that we don't do anywhere else... is it a confusing API because of that?
<aaronlev> alice: how about we let the author decide what they name the attribute on the outside, this also fixes the bottleneck problem
<alice> aaronlev: I don't think I follow, could you write out a code snippet as an example?
<aaronlev> aria-forwarded="aria-labellebedby=data-labelledby-textbox"
<aaronlev> aria-forwarded="aria-labellebedby=data-labelledby-textbox"
BenBeaudry: my brain cannot process, can you go back to cross-root ARIA
BenBeaudry: we only have one element in the shadow dom.. and we are linking it to the arialabelledby property... we can't have a second aria-labelledby in the shadow dom? this is the bottleneck problem right? (right) so what is the solution, how does the "encapsulation-perserving idl element"
alice: for the semantic delegate proposal is a limited solution to a specific problem. this is a pattern that some people are doing. taking an interactive element, putting it in a shadow root, and it is just a "fancy" input.
alice: crossroot ARIA only solves this case.
alice: "encapsulation-perserving IDL element" describes WICG/aom/issues/195
sarah_higley: I was going to try to elaborate on weirdness: there is an element I find weird, but it is when you go beyond atomic inputs. a slightly more complex date control with input and button. aria-labelledby is used for both the input and the button/popup
sarah_higley: typically you are setting aria-labelledby for one specific thing, not many things
sarah_higley: in this case, it might apply to many things
benhowell: this doesn't apply to semantic delegate
benbowell: because you can only apply it to one element
jamie: when you have a component that is multiple components. how is this not an issue for a visual components, don't you have the same problem?
jamie: if the calendar has multiple controls, shouldn't the label apply to the group role?
jamie: it feels to me if that is the problem, the component implementation is wrong somehow, that is how it seems to me
sarah_higley: as someone who has authored many components. If we have a label string for react component, it usually is for the main component, but there are other things (like close button) that is built off the label string.
sarah_higley: there is multiple ways to build this from the component author perspective, but if you are consuming the component, I feel its weird because you aren't sure what it does
jamie: the best parallel I can think of is video controls. the label applies to the container. We don't need to apply to the label to all those buttons inside the group, like pause/forward/etc
jamie: the user already has that context. I don't need hear "play adorable video about puppies"
jamie: "play" is ok
<Zakim> cyns, you wanted to mention that the label needs to be on the focusable element not the group containing
jamie: the group should be read contextually
jamie: the group label should be read when navigating in
jamie: why is the component consumer supplying a string for an internal label
cyns: searchbox. it has a text input and button and pretty stuff. it can be used on different pages. the author would supply "search puppies" or "search my documents" or "search the web"
jamie: ok but there is only one thing that needs to be labeled
cyns: calendar control, each day has a number, but you want to label it as christmas
jamie: why is this not a probem outside of ARIA? why is this ARIA specific? how would a component consumer do this for visual ui?
sarah_higley: describes "tags" which are a bunch of pill shapped tags. there is an input to add new tags. there should also be a group label for the group of already selected tabs
jamie: the input has a generic label, the group is labeling the input and tags?
jamie: if it was a tags field, "enter new tag" for the input, it is generic
jamie: visually you know what the input is for
jcraig: if you were to land on a group with the label, you get the label for the group, you move into the search field, it can have a generic label "search"
jcraig: but if you tab and cross the boundary to the group, you will hear "puppies group search"
or "puppies search"
<Zakim> cyns, you wanted to ask what are our next steps to make progress on cross-root aria delegation?
jamie: any screen reader that doesn't do this it is a bug
nolan: in terms of next steps, we will have another meeting in AOM
nolan: mostly this is for informational purposes, to bridge knowledge gap between these two groups
alice: we want questions, jamie and sarah's quesiton about case where these APIs make weird, please file bugs on AOM repo
alice: put enough info so we can understand what API you are talking about.
alice: if you can think of scenarios which need to be supported but aren't, that is useful
nolan: the web component want this yesterday. the feedback however, is that maybe you don't need this, you are doing something wrong
<cyns> Please put issues here https://
jamesn: I feel like we need this yesterday
<jcraig> WICG/
some discussion of: WICG/
jamie: concern why this isn't just a browser internal
jcraig: "I believe everyone who has discussed this (in AOM, ARIA, WPT, and BTT) is in agreement that this should remain a test-only, read-only interface for the currently foreseeable future. Unlike a prior AOM experimental implementation, this is not intended as a web authoring API."
jcraig: how we implemented I don't care
<jcraig> https://
jamie: the main reason this matters at all, getcomputedrole is a webdriver thing. as I understand it, you would be getting an interface, and you can make direct calls, its not async
jcraig: I was thinking maybe you get a static copy of the accessible node, all the string properties and ids
jcraig: if you need to walk the tree make another webdriver call
jcraig: walking up via dom though, this might be a read only json dump
jamie: a property bag instead of an interface?
jamie: sounds like we are on the same page, sounds like you are open
jamie: gecko has a weird implementation for part of this
jamie: but now I'm thinking of removing that code
jcraig: the old AOM accessible node interface was suppose to be a web authoring API, writable
jcraig: most can be stripped out. maybe you could save some as an implementation detail
jcraig: can't discuss this in WPT repo, maybe aom or subgroup of AOM, should happen in w3c and whatwg
jcraig: for now look at AOM meeting agenda
Virtualization - please read explainer for background
jcraig: I think this should be discussed in OpenUI
jcraig: in my opinion this should have keyboard support
Matt_King: it needs query support
Matt_King: even if it is an open UI pattern... isn't ARIA is the group where we have the most stakeholders
jcraig: I'm saying it should work by default, not just for AT
jamie: are you saying lets standardize infinite scrollers?
Matt_King: you can already do these things and not care about AT. there are companies with huge back end infrastructure to do all this stuff already
jamesn: honesly it is hard to do well even when you don't have about AT, if you just care about keyboard users, if you have focus on a grid and you scroll what is focused out side of the screen/outside of what is even there
jamie: that is true for a lot of other things that openui is doing
jamie: we have been doing popups and select menus for years, but OpenUI is trying to standardize so that you can do this easily and without downloading huge libraries
jamesn: I agree but it might take forever
jamesn: that is can be done in open ui but (see previous comment)
Matt_King: seems to me like there should be all these special cases
Matt_King: I don't know how you would do this without knowing that an AT is running, that is the problem with this proposal
jcraig: I think the idea is that it is a marker on the container which says try to keep scrolling once it seems like you have hit the end
jamie: I feel like this proposal is implementable without focus
Jamie: it's just a matter of scrolling to a different place
Matt_King: if you say scroll to next header, you don't know if you can scroll to the next header, so just keep trying to scroll until you get to a header,
Matt_King: seems not performant
jcraig: you can't search for a string
jamesn: browser search doesn't work either
jcraig: if it was a mainstream interface... everyone would exercise the same methods
jcraig: and it would be more performant than "scroll/test/scroll/test"
DougGeoffray: can you say "take me to the next thing in your canvas"
jcraig: desktop browsers already intercept cmd-f / ctrl-f and do server side
Matt_King: I want to bring this up because it has been sitting around for a while and nothing has been done
jamesn: we should deep dive this
The relationship between ARIA and ATs
<BenBeaudry> Here's the WICG page about aria-virtualcontent: WICG/
JAmesn: What are we doing well and not so well dealing with AT?
Synthia: It has been weird to me that much of the accessibility standards are about finding ways to work around bugs instead of fixing them
… I'd like to change that approach
Matt: I think it would be good to introduce new people to the ARIA-AT CG, and show what we have done
… In 2018 I formed the ARIA-AT CG (ARIA and Assistive Technologies)
… I worked with Michael @@@, who is before a11ysupport
… There ar ea number of other projects out there trying to work on how well ARIA attributes are supported by AT
… We determine a reasonable set of expected behaviours for AT
… We started with desktop screen readers
… In practice we have the experience of web authors who don't know what to expect
… Working to engage with different stakeholders
[...] Matt shares screen with project home page
<jcraig> https://
Matt: We write a set of expectations, and when we reach consensus they are part of the test suites
… Our deliverable is, for example, we want to define a set of AT expectations in the form of text. Get consensus on what those test are.
Synthia: Why is it not a spec?
Dainel: It needs to be run through the ARIA WG for it to be able to get to REC
S/Dainel/Daniel/
Matt: We are using APG examples as reference implmentations
… People who draft the tests are screen reader users
Matt: We establish what the most common behaviours are, we compare it to non-web behaviours where they are supposed to work
… Once this research is done they write a draft test plan
[Matt shows the radio group draft test plan and test runner]
Matt: These include getting to the first element, getting to the last element, using different ways of navigation commands, different reading modes, etc
Matt: We have three main categories: navigation, reading, and operation tests
… For each test and screen reader there are instructions
JamesC: The high level overview in two sentences is this is a set of manual tests where the expectations have been reviewed by the technology owner
… The goal is not to ensure uniformity, but to ensure the semantics are conveyed in some way
… In the case of the check box, the state is conveyed, each AT may have a different approach though
JamesN: How far we are to have tests for the rest of the patterns?
JamesC: cyns said This should be a spec
… non-web AT behavior out of scope for WAI, it even exceeds the scope of the parent W3C org
… I would not like to get very prescriptive on how AT should behave
… Also, anything that is a spec may have an impact on how some things apply to later technologies
… For example, keyboard shortcut references in ARIA before the iPhone came in
JamesN: We do have normative statements in the ARIA spec for AT
… There are about 30 AT should and should not, and some may. I think not having must is good
JamesC: Normative statements about AT should be very careful and mindful of scope
Synthia: What I would be willing to see may be out of scope of ARIA
… We drew a line between what should be standardised and not for browser, I don't see the difference with AT
… There are rules about how to render a select
… I think this is a nice first step, but I don't understand the difference
JamesC: We need to go in a case-by-case step
Synthia: There are not must though
Matt: We are looking for examples that are problematic for developers. There is still discussions of some specifics
… When there is a state change, everybody was aligned to require some sort of indication
… I am not sure how to put these things into specs yet, but we should be able to communicate to web authors how the code you wrote is supported by AT.
JamesC: These scenarios are probably bugs
Synthia: Still no one is saying what should be right
Matt: Hopefully the consensus around the test plans would allow to get newer browser and SR versions to the same page
Jamie: There are spaces where there is still not pixel perfect rendering on the Web for example in video
… As JamesC was saying before, we don't have to talk about exact SR UI, but about the intent
… In the case of the state, we should state clearly that there must be an indication
… I had comments that our SR did not meet the spec and also I did not find clear guidance about what to do
… AT should not be pushing back against guidance about the requirements, and we should be careful dictating the precise UI for these
Jamie: Having that guidance benefits everyone as it avoids authors thinking that ATs do not follow specs
Matt: We are trying to solve that problem here for at least the ARIA patterns defined in APG. We want to go beyond that.
… Also trying to tests the HTML versions of those when they exist
… Testing them in isolation does not produce useful results
… Eventually we would be able to run these tests automatically through the test driver
S/test driver/AT driver/
JAmie: The tests are a manifestation of that guidance
… We need to make sure the new AT respects that but we may not be able to determine that as there there are no specific expectations for these
Aron: I am concerned about the new stuff that is coming out. How does the screen reader know that these are there, how does the user navigate
… T this point if we can demonstrate that screen readers are doing it right we can support authors in implementing these patterns
Matt: This is the kind of discussions we can have in the ARIA-AT
aaronlev/gi: Sometimes standards people come to us with good ideas of markup because they see accessibility as a selling point for creating them, but then the gap is with AT because we don't know how they are going to interpret these
Sarah: +1 to aaronlev's points. I am wondering what we consider AT. It is not just screen readers, the degree of API consumption is very different
<aaronlev> Maybe we need an incubation group
Sarah: I am curious if you have defined scope as to how these differences could apply especially for non-screen-reading technologies
<aaronlev> where the new stuff is born, and eventually we can hand it off to the main group to make it more rigorous
Matt: We are trying
… This comes especially on the AT driver conversation, but also on the backend of the AT website
DougG: I love this idea. Are expectations using the default settings of screen readers? Maybe some things are not even exposed
Matt: If there are some screen readers that are exposing some things by default and others which don't, what should be a consistent approach?
DougG: I'd hate to see that flexibility taken away from screen reader vendors. They do things mostly based on what they users ask for
cyns: There should be a part that works the same and other where there could be differences.
Jamie: AT can file bugs against specs if they think something should be amended.
Dug: The verbosity levels are almost not present in browsers
<Zakim> jcraig, you wanted to talk about AT UI differences
Synthia: The rules for browsers are there already
JamesC: Browsers used to refuse spec rules for them. There are now many more similarities.
… People don't realise how different some screen readers are from each other
… Switching takes more effort for screen reader users as they need to get used to a new OS pattern and a new screen reader pattern
… Agree with Jamie that it needs to be clear what AT should convey, but not get into the details as to how they should be conveying things
<Zakim> aaronlev, you wanted to say that ^
Matt: We need to make sure that some things will be rendered and some other could not be rendered, so that authors are continue of the implications of using different approaches
Aron: I think we can start at the incubation level where it should be clear how it works, and then passing it along to the other group where this can be further developed and implemented
JamesN: We have fewer browsers and they are involved in the standards they have to comply with. We do not have so many ATs involved. If they are not involved, chances are that we fail
Matt: I was hoping that the ARIA-AT would provide such communication channel and that it could be the place for innovation
aaronlev: It could just be a parallel effort, with different people and different approach
… The way I did it with aria-details is I started a brainstorming process with users, ATs, browsers, etc
… It was less of a weekly meeting and instead it was more of an asynchronous work with recommendations on how the thing should work
Matt: That is exactly what we do in the first phase. Then we extend it more in subsequent conversations
Jamie: Voice Control does not convey anything
JamesC: It does, it can show labels on screen
Jamie: There will be AT for which some requirements would not apply
Sarah: I am unclear if this is about developing requirements or expanding testing.
Matt: I am not talking about developing normative requirements at this point.
JamesC: Something needs to be in here for these other ATs
… Since the beginning VoiceOver has had support for speaking text under mouse
… Sometimes the boundaries are not so clear and fixed
Matt: Clasifying AT might not be the paradigm, but rather the intent or the purpose
Jamie: If the user is relying on assistive technology that conveys content, this should be conveyed.
Ben: +1 for a separate incubation group for these kinds of things
<jamesn> +1 for a separate group too
Ben: We have in this group very technical knowledge, we don't have the other part though
<Zakim> jamesn, you wanted to react to jamesn
Matt: We need to work on innovation for web technologies. Sometimes we are associated with the motion and leadership of specific groups. I would like to use ARIA-AT for these incubation purposes
JamesN: I can understand the desire to have this, it is potentially time consuming. It would require multiple implementations from browsers and AT, and it is hard
Synthia: The change from W3C to have implementations before the spec goes out was a very positive thing
JamesN: If we only managed to have a separate entity
S/we only/only we/
JamesN: With Core-AAM being ever green we can have the browser implementation
Synthia: The issue is what happens when a trendy web pattern does not work with AT
… Currently that gets added to browser specs or to WCAG
Rashmie: Sometimes we focus on the screen readers but there are other use cases. For example, having aria-label does not fix issues with visual labels
Synthia: Sometimes the but is in the screen reader, engineers are right and it should be AT which needs to fix the problem
<Zakim> jcraig, you wanted to address the incubator comments
JamesC: These things are the ones that WICG is supposed to work on
… All browser vendors are in it
<DougGeoffray> Something I heard a very long time ago and use it all the time.... "The great thing about standards is there are so many to choose from"
JamesC: If there is a new feature maybe that is the place to discuss it
Matt: The ultimate goal of these support tables is that authors will know when this is ready based on these numbers
<Matt_King> W3C Blog post announcing AT support tables in APG and providing background on project and its relationship to WCAG "Accessibility Supportted": https://
[JamesC shows a feature (Mac HoverText) where the label is conveyed as per user request]
Sarah: Most of the times when we say AT we mean screen readers, and there are other things. The idea of scoping it using "conveying" is interesting. The label, for example, is what should be conveyed. I'd like to avoid writing normative stuff for assistive technologies but really just thinking of screen readers
JamesN: We want to spec more on these things, we are not sure how, though. Maybe the ARIA-AT is a good place, the ARIA spec may be not the place
Matt: Maybe not what we are doing now in AT, but if we are able to scope it well, it should not shy away from the spec
JamesN: I am OK with that as long as we get buying from AT vendors
JamesN: There is a lot of things that AT is not doing a good job with. Like for example with aria-invalid
Matt: That is a perfect example
JamesN: Maybe we should come back to this in a week or so
Synthia: Should also try to get some more traction with other AT vendors
Aron: Doing it informally for a while may be useful, kind of under the radar
Matt: Let's see if we can collaborate on this. The people that are writing these tests are interested in what you are talking about. If you are open to bringing these things to the CG agenda and work in there, I think that would be great
Aron: Sounds good
… Feedback from people that are both authors and users is great, then we have to add the screen reader vendors feedback and find the right approach to that
JamesC: The scope thing is critical. Attending weekly meetings may not be suitable for people, whereas more informal communications may be better