Meeting minutes
New Issue Triage
jamesn: For ARIA #2634, no examples that demonstrate the issue therefore, not an ARIA issue (but may be accessibility or html-aam). Should this be agenda +
spectranaut_: it may be a simple misunderstanding, unless someone wants to volunteer (to take a look)
Stefan: sounds like a question around "what can be contained in what", and is it a violation of something
front-endian-jane: I can take a look
sarah: I'm working on a draft PR for ARIA issue #2631. Could use an Agenda+ due to open questions
jamesn: for core-aam issue #252, this looks like a misunderstanding. Perhaps James Craig can clarify (can we close this)?
jcraig: yes, go ahead and close it
New PR Triage
jamesn: don't need to look at ARIA issue #2633 because it's pdf-aam in draft status
spectranaut_: I can take a look at ARIA issue #2632
WPT Open PRs
jcraig: nothing new to discuss, closed out a few. Val/Rahim/Giacomo, any to discuss? ARIA PR #2237 awaiting response
giacomo-petri: I tried to find a compromise, I liked James Craig's proposal which is clear. They are basically doing the same thing, so happy to go either way
jamesn: my proposal was a suggestion, not blocked on it. If you prefer to go back to a different way to phrasing, I'm OK with that
front-endian-jane: I haven't seen this comment yet; if the other one works, I can close mine (and hopefully close the comment if it addresses everything)
jcraig: as long it doesn't change the WPT, the test can be merged
<Zakim> Adam_Page, you wanted to ask for review on web-platform-tests/
Adam_Page: I've got an older WPT PR that is ready for review (a `aria-owns` vs `aria-hidden` test), WPT #44822
<spectranaut_> Rahim: I want give a heads up there are two wpt that recently got merged, role case sensitivity, IDL tentative tests were merged!
TPAC planning
jamesn: do we have a meeting with AG scheduled?
Matt: I had a conversation with Daniel yesterday, wants to make it broader than ARIA AT discussion and being more broadly focused on all the different kinds of testing concerns. Lots of ideas in this space, and he (Daniel) is reaching out to different people and he'll be in touch with you (James N.)
jcraig: if Daniel wants it broader it could be accessibility Interop rather than AT interop
giacomo-petri: there might be interest in the ACT group committee to participate, quite relevant for us (ARIA WG). Daniel is aware of this interest
pkra: ARIA issue #2623, I agree that they're the same (label from name and contents)
jamesn: this is a reminder that F2F candidate issues will be on the agenda. We should delete ones we don't think we'll talk about, can do that offline (during planning). Please add your topics using "F2FCandidate" label
… will go through and create an agenda with these
Editorial: [html-aam] Add <abbr title="..."> platform a11y API mappings
Rahim: should `title` be discouraged with `<abbr>` element, and this should be documented outside of html-aam, right?
jamesn: I think `<abbr>` experience needs to be fixed, not an ARIA issue
jcraig: Ideally test how it should be mapped, can't do it through WebDriver test but can do it through browser layout tests. That's an upstream task than the AT side of it
jamesn: about providing equitable access for all users; not talking about AT users, but what about keyboard users (don't get that information with current implementation). If you use `title` for conveying anything useful, that's a WCAG violation
… would discourage everyone from using it
<Zakim> spectranaut_, you wanted to write a note in mdn...?
spectranaut_: good place to document this is MDN (in a note)
Rahim: I can write a note for this. Should the ARIA WG review the note beforehand?
jamesn: Other approvers for MDN, out of our control. If you want to ask people for review, you're welcome to do so
… I agree that having better mappings would be great for more consistent AT behavior
Rahim: how should this be actually mapped (e.g., how does it work when something is announced on demand, and where does html-aam fit into that)?
Matt: these are AT requirements, not user agent requirements. I don't think they belong in html-aam at all. If we had an AT requirements, they should go in the ARIA spec, and we've been very careful about putting them in (shouldn't put anything that is AT-related in an AAM)
jamesn: I agree, and I don't think it should go in ARIA itself as well (is there any ARIA impact for this)?
… the role mapping for this doesn't have an ARIA role; I don't know how we would add something in the ARIA spec that would cover a native HTML feature that doesn't have an ARIA mapping
Matt: so, we're saying there's no implicit ARIA semantics at all
jamesn: I think not
<Zakim> jcraig, you wanted to discuss even "on-demand" is prescriptive and to suggest HTML-AAM ~"should make the expansion available to the APIs"
jcraig: the language I objected to was similar, but even "on demand" is prescriptive because depending on context, you may want to speak it as part of the name in some circumstances, or may want to wait for the name. To me, "on demand" means user can trigger a keypress/action to hear it when they want
… agree it shouldn't be documented in ARIA spec, but in html-aam spec, could make a user agent requirement that expansion should be available to accessibility platform APIs. Table we put in there is normative anyway, don't know if we need an extra RFC statement
… if this is a secondary requirement to the normative mapping, I agree with Matt; we've kept AT requirements out of specs because this is an area for user interface differentiation
… even focusing on default settings, worried that we'd be getting too prescriptive and preventing innovation
giacomo-petri: I agree with James, as I mentioned last time, the `abbr` element presents challenges for screen reader users but for other users with disabilities, should be up to them
jcraig: could be practices as informative, non-normative documents (e.g., XR accessibility guidelines which are written as non-normative) which allows for not following particular guidance in case it doesn't make sense for some innovation change
Matt: the html-aam, if providing a specific mapping and that mapping is somehow problematic, then I would expect that to show up when we do screen reader interoperability during testing (if it doesn't show up in any other way). This could result in some feedback if it doesn't change mapping, or aligning screen readers for how to process that mapping
… if the html-aam just sticks to saying "in this condition, map X to Y", this can be tested and evaluated and people can make determinations on whether that normative mapping is effective, ineffective, needs to be changed or fine the way it is
jamesn: how should we progress?
Matt: I'm saying do we need a note and additional clarity on mapping?
Rahim: my main question is how this should be documented in terms of mapping
jcraig: I think the only action here is, already have a draft PR. You (Rahim) and I can work on what the appropriate AXAPI mapping is. Also, need the platform maintainers for other platforms to tell us what those are (mappings). There are potential downsides to adding AT requirements, let's focus on mapping API; as implementation for each of those engine bugs go in, in the short term, can add them was layout tests (or whatever other engines use
Matt: one of the reasons I want to do the TPAC workshop; let's put these test cases in ARIA-AT and make them run. In this manner, when developing new ARIA features, can determine what AT is doing/not doing, and discuss what changes are needed to mapping, AT (or both)
Rahim: next steps are to add a note, and also document those mappings
aria-keyshortcuts: Do multiple shortcuts define a set of alternatives, or a single sequence?
jamesn: concern when multiple key shortcuts are space-delimited, do those separately or as a sequence. My understanding is that they are alternatives, but good to clarify notation for consecutive key shortcuts that could apply for something
Matt: having a notation that says "this is a shortcut that consists of something happening in succession", would be helpful
jcraig: Aaron L. was the champion of this attribute (`aria-keyshortcuts`), should have one of the Google reps be involved. Also, for VoiceOver, has shortcuts that are essentially "overloaded" keys. This is one of the attributes that I had reservations about, but Aaron convinced me. Main reservation was that you can't do platform-side localization of these, juts have to do web-app localization side
… Aaron's argument was that Gmail, in France, will pick a shortcut work for a French language for a French keyboard; the language will be localized to French in France so not a concern for the AT/platform side of things because web author has already done that
… whatever we pick here, we include appropriate notes emphasizing how difficult this can be for web authors
front-endian-jane: I can confirm reading this, spec does a good job of outlining challenges. If there additional edits, should specify those
jcraig: there's also a space-separated aspect to this, may not be clear as to comma vs. space separated definition
… in ARIA spec, see "examples include simple characters..." and this might be the overloading, but unsure
jamesn: needs specifying, I agree
front-endian-jane: it's currently undefined. My concern is that if we take the current separator and define that as separate shortcuts and not consecutive ones, for apps in the wild they may have interpreted in a specific (non-spec compliant way). From a real-world perspective, the types of apps that have consecutive app key shortcuts, tend to be advanced
… may change the meaning for people if we don't call it undefined
jcraig: if we have examples that don't use space separator, could leave that as undefined
front-endian-jane: is there concern that it adds complexity for ATs (now 3 different states)?
jcraig: absolutely
jamesn: would like to see what ATs do, and problem worth solving. How well is this implemented by ATs
Matt: not sure I've ever seen an implementation
<Jacques> simply speaking the keyboard shortcut string was my recollection as well, at least on windows.
jcraig: I recall Aaron may have worked something through on the Windows side, but I believe it was about speaking what is (or concatenating at the end of something, a string) and the only difference on why it needs to be a separate feature part of the label is due to verbosity expectations ("alt," announcement)
<pkra> this feature request from Aaron based on a non-standard JAWS feature might also be relevant in this context w3c/
Matt: one consideration is what characters get spoken as part of verbosity; also, in screen readers like JAWS, different voices for different types of content. Another consideration is turning of speaking keyboard shortcuts on or off (can't have that feature to turn it off if you don't know)
… three reasons why an AT user would want to know it's a keyboard shortcut and not part of the label
… not aware of any implementations
jamesn: is this something we need to solve? If it's already ambiguous, users may get confused as what they can do
front-endian-jane: as an implementor, I would be OK to call this undefined and read out (here are keyboard shortcuts that exist), it's on the app implementors to do it. In the same way, it is displayed visually as a space-separated list of keys
Matt: keyboard shortcuts wasn't designed to be help text but rather tightly restricted content; there isn't an opportunity to make it clear with the property itself. This may be a problem for all users and ambiguous but up to user to experiment to learn how it works (may not be the same for every app)
front-endian-jane: I can work on putting together a PR
pkra: wanted to mention ARIA #2351, a feature request from Aaron L. to standardize page-wide shortcuts which was non-standard from JAWS. Keith mentioned a related OpenUI proposal
keithamus: on my to-do list
jcraig: a quick note which will be editorial, regarding the example from aria-keyshortcuts discussion and numbers being on the Shift plane. I will file a PR that changes ARIA spec to Shift
<Rahim> s/I think the only action here is, already have a draft PR. You (Rahim) and I can work on what the appropriate AXAPI mapping is. Also, need the platform maintainers for other platforms to tell us what those are (mappings). There are potential downsides to adding AT requirements, let's focus on mapping API; as implementation for each of those engine bugs go in, in the short term, can add them was layout tests (or whatever other engines use /I
think the only action here is, already have a draft PR. You (Rahim) and I can work on what the appropriate AXAPI mapping is. Also, need the platform maintainers for other platforms to tell us what those are (mappings). There are potential downsides to adding AT requirements, let's focus on mapping API; as implementation for each of those engine bugs go in, in the short term, can add them was layout tests (or whatever other engines use for engine-specific tests that aren't testable with WPT) for
engine-specific tests that aren't testable with WPT)/
<jcraig> That editorial PR for shortcuts i18n I just mentioned is now available. w3c/