Provide warning for using roles that aren't fully supported in browsers

[backwardok]

There are some roles (like slider and spinbutton) that have related accessibility events (like increment and decrement) that are not exposed in browser APIs currently. Native equivalents (<input type="range"> and <input type="number"> respectively) have some support (when testing with macOS VoiceOver in Safari, the range accepts increment/decrement events, but number does not), but when using the ARIA pattern, this results in making the request to increment/decrement but no resulting change in behavior (since there's no JavaScript event to listen to in order to add the behavior in).

It would be helpful to add warnings for some of the patterns that result in allowing AT events that cannot be supported currently in browsers.

[jnurthen]

I think this is a duplicate of #8

[backwardok]

It's kind of related to #8, but doesn't just affect touch devices. Even when using a keyboard + desktop SR, the same problem exists.

In chatting about this with @scottaohara , he suggested adding extra information on the gaps of certain patterns on the example pages.

[jnurthen]

Yeah ok - it is more VO (and maybe Talkback too I can't remember whether they fire up/down key events on increment/decrement off-hand)

[scottaohara]

to clarify, i didn't mean to indicate that i think all gaps should be accounted for. that'd be a lot of work/upkeep.

As i mentioned in #8 i'd be perfectly happy with a clear link/reference to sections 2.2 and/or 2.3 to remind developers "Testing assistive technology interoperability is essential before using code from this guide in production"

[mcking65]

We discussed this in the August 6, 2019 APG task Force meeting. See Minutes for topic APG language for new ARIA features.

Note that browser and assistive technology support are outside the scope of the APG. Browser support is addressed by automated testing during the ARIA candidate recommendation process and assistive technology support is being addressed by the w3c/aria-at project.

Sometime next year, we may have the capability to link to assistive technology support data from the w3c/aria-at project from the APG.

In the mean time, as Scott points out, we refer people to the need for thorough testing as described in section 2.3.

[mcking65]

This was discussed again on September 10, 2019.

We will consider a PR that scopes a warning statement to alerting readers to support gaps that can only be resolved by development of a new technology, such as AOM. These gaps are distinctly different from browser or assistive technology implementation bugs, which will be covered by the aria-at project. The aria-at project objective is to provide assistive technology support tables that can be integrated into each example page.

In the September 10 meeting, @charmarkk suggested he might be able to draft a PR for the 1.2 release.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 1150 - support warning.

The full IRC log of that discussion

<carmacleod> TOPIC: Issue 1150 - support warning
<MarkMccarthy> This widget may have support gaps that can only be filled by the development of new technologies. Authors should fully test this widget before using it for a production ready project. Likewise, it may be poorly supported by certain browsers or assistive technologies.
<carmacleod> github: https://github.com//issues/1150
<carmacleod> mark: wrote it so it can be generically used
<carmacleod> mck: if it is so general that it doesn't give any idea about what the gaps are, then users won't know if it affects them
<carmacleod> mck: should we scope this warning to just be mobile, touch screen, or similar?
<carmacleod> mark: open to making that change if others agree
<carmacleod> mck: ... assistive technologies offered via touch interaction ... ?
<carmacleod> mck: do we want to use the word "widget" or "pattern" here? Or "widgets implemented using this pattern"?
<carmacleod> mck: might depend on context (i.e. does it appear of pattern page or example page)
<carmacleod> mck: do we need the "Likewise" part?
<Jemma_> "This widget may have support gaps that can only be filled by the development of new technologies. Authors should fully test this widget before using it for a production ready project. Likewise, it may be poorly supported by certain browsers or assistive technologies."
<Jemma_> +1 for Matt's comments on the first sentence
<carmacleod> mck: maybe first sentence and last sentence are redundant?
<Jemma_> other than this looks great, Mark
<carmacleod> mck: which examples need this, other than slider?
<Jemma_> s/than this/than that, this
<carmacleod> mck: add it to slider first, then duplicate as needed
<MarkMccarthy> Thanks Jemma
<carmacleod> mck: new technologies like AOM
<carmacleod> jemma: "new technologies" sounds vague - maybe we need to specifically include AOM?
<carmacleod> mck: don't want a dependency on AOM in wording
<Matt_King> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/09/24-aria-apg-minutes.html Matt_King
<carmacleod> zakim, who is on the call?
<Zakim> Present: Matt_King, jongund, MarkMccarthy, Jemma, ZoeBijl, evan, carmacleod, Sarah_Higley
<carmacleod> zakim, bye
<Zakim> leaving. As of this point the attendees have been Matt_King, jongund, MarkMccarthy, Jemma, ZoeBijl, evan, carmacleod, Sarah_Higley, curtbellew, jamesn
<carmacleod> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2019/09/24-aria-apg-minutes.html carmacleod
<carmacleod> you're welcome jemma!
<carmacleod> bye for now
<Jemma_> bye

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 1150 - support warning.

The full IRC log of that discussion

<ZoeBijl> topic: Issue 1150 - support warning
<ZoeBijl> PR: https://github.com//pull/1186
<ZoeBijl> github: https://github.com//issues/1150
<ZoeBijl> MK: We got an updated text from Mark
<ZoeBijl> Pretty happy with this
<ZoeBijl> Have to fix spelling of AT
<ZoeBijl> > Widgets implemented using this pattern may not currently be fully supported by assisitive technologies operated based on touch interaction.
<ZoeBijl> “fully supported by touch based assistive technologies”
<ZoeBijl> s/“fully/ZB: “fully/
<ZoeBijl> JN: Should point to the interaction part
<ZoeBijl> MK: So maybe “Interaction with widgets implemented using this pattern may not be fully supported by touch based assistive technologies”
<ZoeBijl> s/MK/ZB/
<ZoeBijl> *group agrees*
<ZoeBijl> MK: Does that make sense to you Mark?
<MarkMccarthy> I like it, I can change that this week
<ZoeBijl> MK: OK, sweet
<MarkMccarthy> Thanks for the feedback friends
<ZoeBijl> JN: Are we OK with the horrible looking alert icon?
<ZoeBijl> ZB: No!
<MarkMccarthy> I also had an objection to that icon, or at least changing a little bit of the styling. Glad it’s not just me...
<ZoeBijl> MK: How would we solve this?
<jamesn> https://github.com/w3c/respec/blob/092e9788b58c342da35378ec29ef26fbb002b4c7/assets/issues-notes.css#L25
<ZoeBijl> JN: I think Marcos would accept a PR if we made one against respec
<ZoeBijl> ZB: I can make a PR.
<Jemma_> +1 to jame's solution
<MarkMccarthy> On mobile sizes it looks rather janky.
<Dorothy> Dorothy is a CSS expert
<Jemma_> Resolution: Dorothy would work with Zoe to create PR to fix this CSS.
<ZoeBijl> https://github.com/w3c/respec/issues/2531
<Dorothy> dorothy.bass@wellsfargo.com
<Jemma_> s/Resolution/RESOLUTION

[mcking65]

Commit eec5af6 resolves this for slider patterns.

We now need to decide if we need it on any other patterns. There are some useful comments in PR #1186. This is a topic for the February 4 meeting.

[carmacleod]

Discussion from Feb 4 meeting.

[mcking65]

The warning about API gaps has been added to slider and spin buttons. All examples now also have stronger language related to testing mobile support.

I think we can close this now.