Meeting minutes
New Issue Triage - 👻
jamesn: For ARIA #2368 is about the new updates to <select>
scott: I will talk with OpenUI about this today, but I did want to get this in the triage so it can be agenda'd. I'm interested in people's thoughts
spectranaut_: For core-aam #240, this is a question for Apple folks, and how to implement accessibilityRowCount for row content
jamesn: Assigning to James Craig
jamesn: *Unable to understand Mario B. due to connection issues*
jamesn: Should ARIA #2364 be agenda'd? Is this necessary to agenda, or should it add it to interactive lists so that when it's being considered, it's also considered with that?
… is there an issue number for that (interactive lists)?
jamesn: Referenced ARIA #2036 for the interactive lists issue in #2364
jamesn: For core-aam #239, this one is from joanmarie
spectranaut_: About surfacing accessibility content through NSAccessibility API and questions about aria-sort API values mapping (i.e., what unknown means). There's 4 options: ascending, descending, etc.
jcraig: For core-aam #238, removed from agenda because it was not pressing. Some things snuck in through WPT tests, which added new tests. Caused me to find a property that was not supported.
jamesn: I don't think we want to block on actual AT support
jcraig: Issue is no longer pressing
New PR Triage
<jamesn> added: "- If a working group member is not sure about whether a PR's change has consensus, they should add the tag "needs consensus" and "agenda", and it will be discussed in a meeting."
<jamesn> AND **AT Commitment:** If the feature requires a change in AT, add the tag "waiting for AT commitment". AT Commitment should be record in the comments of the PR.
spectranaut_: ARIA PR #2367 is about when a change has consensus; we've talked about it via reviews from those that have the most opinions. Can tag issues as "needs consensus" for further discussion; also tag for issues that need AT commitment (from vendors)
jamesn: For any comments, please add to the PR
jamesn: For ARIA PR #2366, adding an "AT Guidance" to PR checklist
<jamesn> * [ ] Does this change need AT guidance?
<jamesn> * [ ] Does this change have AT commitment?
scott: For ARIA PR #2365, would like implementers to review it
… there are callouts for posinset and setsize. The bits that are unique to this (element) and customized select work, I've added comments indicating that user agents might need to do something about invalid nesting of interactive elements within an option. Needs to be accounted for along with UA provided options
… another comment for reviewers/implementers would be for listing accname steps for options as well
aaronlev: Yep, add me for review
jcraig: Yes (add me too)
jcraig: For ARIA PR #2362, this is the only missing value in 1.3 as far as I know
… colindextext and rowindextext
jamesn: should Joanie review this?
spectranaut_: or me, I can look
jcraig: Presumably, this would be something that Aaron/Jamie would implement; no real way to test it other than testing AAM. No screen reader reader support yet on Mac
… no screen reader support for AXAPI mappings on any platform
WPT Open PRs
jcraig: Everything new since last week has been merged; there has been several test changes and one metadata change related to this. Some new tests were added late to the a11y interop area, which will be rolled back
Complex Dashboards deep dive time planning
jamesn: Identified 2PM pacific time on the Nov 14/21 for a deepdive on this, is there a preference?
… would want Jamie Teh (Firefox) to be included in this discussion
aaronlev: I prefer the 21st
jcraig: Will the Zoom link be the same as the ARIA one, or added to the ARIA calendar?
jamesn: Yes, it'll be on the ARIA calendar
Recharter - ping your AC reps to reply to the survey
jamesn: We have currently 13 positive reviews for AC representatives; thanks to the reps that have replied to the survey. For those that haven't, please ping your AC rep to respond positively to the charter, and give constructive comments on what you can do to improve it
dmontalvo: Next week, I'll start sending reminders for the AC reps that haven't responded
jamesn: Tetralogical, Apple, Adobe, Google, BBC, Microsoft have replied already
Inconsistent author/ua restrictions for columnheader / rowheader
spectranaut_: When we talked about this in triage, we figured it might be the same (for columnheader/rowheader). Might be a good first issue for spec editing
jamesn: Let's mark as "good first issue"
jcraig: I'll do that for the WPT issues as well
Reconsider whether ARIA should ship new features that have incomplete API mappings and missing AT support. agendabot]
jcraig: This is mainly a process change suggestion, I think. There's a couple related issues; one of them is the proposal that core-aam have some kind of listing for known support. We talked about several things, e.g., if we can cross-link to live WPT tests (the way that Bikeshed has, see outstanding ReSpec issue). If there could be a listing or iconography-based thing, like a "Can I use..." for AT support, would allow us to have appropriate
flags
… for rowindextext/colindextext issue, process has been done on the API side of things. Joanie pinged me, and this one fell through the cracks. Will be a full release cycle before maximum screen reader support for that
… this issue is resolved, but extra checks will help as spec gets closer to CR signoff. Not just on the platform level, but give visibility into support for major screen readers. Main ones I'm thinking of are JAWS/NVDA/VoiceOver/Orca, but Narrator may want to be included
jamesn: One of the requirements for a feature is commitment to implementation from two ATs; if it requires AT work in addition to browser implementation
jcraig: Should be two ATs that use different accessibility APIs
aaronlev: What does "not shipping" mean?
jcraig: Doing it to some degree with some of the other PRs; one of the reasons we moved to the monorepo to do feature implementation based on PR preview. I think the goal is to have the ARIA spec, and AAMs, that reflect current reality. A PR should go in when everybody decides what that reality is, but doesn't get merged until it's shown that there is support for it
… I think we should go at least as far show support in the APIs; but perhaps not delay (the merging of PRs)
aaronlev: I imagine smaller companies may struggle to be stronger in their wording; and they may want to express interest
jamesn: If we ship something, but it won't happen for 5 years, not much value for us
jcraig: Screen reader updates ship on regular cadence as part of OS updates
Zak: There will be a lot of AT support that won't be in place; from my perspective, I don't see a benefit of withholding posting the new mappings without support with AT. More of a note to industry on how they should be implemented
jcraig: RE: PDF-AAM, this one is a different case because it will be a working/editor's draft for awhile. Will handle differently because it will publish as working draft; as we get closer to CR, can denote which aspects don't have AT support yet (so can move to a future version)
… the problem with shipping speculative features, which was a problem in the past; spec editors would put features they wanted in there, but wouldn't considered downstream or had active opposition. It's fairly standard across other web specs but with a11y specs, we have a downstream dependency for ATs, which is different than the implementation dependency there is for browsers
cyns: I find it difficult to keep track of everything in development; could some of these PRs be merged into a working draft. Seeing a draft of everything we want vs. everything that is ready (seems better) than making people go through open PRs
jamesn: People aren't just looking at the drafts
<aaronlev> (i never was able to finish my question)
cyns: How does someone know what is coming in ARIA?
jamesn: Valerie and I can think about this more
spectranaut_: We can think about how to solve the greater issue of making clear what is being worked on in the ARIA spec
jamesn: When James C. proposed this change, I think the spec itself is where we should note where AT support is needed rather than the AAMs. I don't expect developers to read AAMs
… which means the PDF-AAM reflects the reality of what PDF is exposing to its AAMs and whether it's supported or not, isn't necessarily relevant at that point
<Zakim> aaronlev, you wanted to react to jamesn
aaronlev: I deal with the practical (reality) of this stuff; often, Chrome is usually the first to do stuff with JAWS or NVDA since we have a relationship with them and pay them to do it. Likely won't be Narrator/TalkBack/Apple
… I would be OK with this requirement if there was one screen reader that was interested, and see how it goes
<Zakim> jcraig, you wanted to respond to Aaron's comment on date commitment and to mention the at-risk or unsupported status as a response to cyns
jcraig: I think it's reasonable to ask for open-ended commitment from two screen readers, and maybe place a status (via icon) such as "committed" or "shipping" with each of those under the features that are achievable. For the committed part, I think that's reasonable and don't see an issue with being able to do that
aaronlev: I would be OK with trying to get two, but don't want to be blocked on my work
jcraig: Cynthia mentioned it's nice to see it all in one place, rather than PR previews. Maybe we don't hold the PR, and as we get closer to CR, then we can mark something is at risk for this version. I.e., at risk for a particular "snapshot"
… being able to call this out on, based on the response for AT support, this (feature) is not yet usable by an author or something like that. One flip side to Aaron's point, speaking generally, there are web features that are developed that may not have full support (dont' want devs using things too early)
aaronlev: I understand the concerns and point of doing it, and I agree. Realistically, for example aria-details needs additional IDs, I would go to Windows screen readers first because they respond to me, are easily accessible
… I don't have a lot of control past Windows screen readers; I agree that we shouldn't promise to devs that stuff works when it doesn't. The counterpoint is that it's hard when stuff doesn't move forward. One approach may be start with one and ensure it's successful, and then add additional support
<jcraig> +1 to ed notes and at-risk notes
scott: My comment is more about the PRs that get made a year ago, and don't get merged. Could this not be resolved by adding editor notes that link to open bugs? I understand Cynthia's point; even in making the monorepo, it hasn't resolved the issue of stuff not getting merged. Still waiting on implementations
<jamesn> +1 to ed notes
scott: if we do this for new features, why aren't we doing it for older features that still don't have great support?
StefanS: From a developer perspective, regarding aria-description for example, JAWS supported it but NVDA did not support it. We got some incidents about this and the end result, they hesitated to take (use) aria-description at all due to lack of sufficient support. More than one screen reader (supporting) would definitely help
<scott> is it enough to just do in the ARIA specs? is this being proposed to HTML as well, for instance?
jcraig: Scott brings up a great question on why we don't do this for older features. Should add these flags to older features; in terms of editorial notes or "at risk" notes, that's OK with me. I'm not saying it should block the PR but it should be noted
jamesn: Do we have an issue in our editor's call for doing these sorts of notes?
spectranaut_: Don't remember it getting that far but I think this is a reasonable one
<cyns> "experimental aria feature"
jamesn: I think we should take this forward, and moving some of these PRs sitting for a long time in the spec with a note about the implementation status attached to them. In the ARIA spec (clarification by Valerie)
spectranaut_: We have to link to issues I think, but we can talk about this more
aaronlev: I think editorial notes are a great idea, and what it's trying to achieve, but think it's a lot more complicated than people understand. I hope Stefan filed an issue with NVDA regarding aria-description
StefanS: In order to raise something as a bug, need justification if it's truly a bug or if it's not currently supported
jamesn: Will discuss this more offline, and in the issue