Slider patterns: Provide warning about inability to operate with touch-based assistive technologies due to lack of needed APIs

[charmarkk]

Partially resolves issue #1150 by adding a warning to the slider patterns.

---

Preview | Diff

[carmacleod]

Words look good!

For others' convenience, here's a direct link, and a copy of the warning paragraph:
Slider warning preview

Warning
Widgets implemented using this pattern may not currently be fully supported by assisitive technologies operated based on touch interaction. Authors should fully test this widget before using it for a production ready project.

[charmarkk]

Updated warning based on 10/1 call feedback (thank you). It now reads:

Interaction with widgets implemented using this pattern may not be fully supported by touch based assistive technologies. Authors should fully test this widget before using it for a production ready project.

If I misunderstood (which is possible) please make a comment.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Support gap warning and support level note.

The full IRC log of that discussion

<MarkMccarthy> TOPIC: Support gap warning and support level note
<zcorpan> GitHub: https://github.com//pull/1186
<MarkMccarthy> Matt_King: we've previously discussed this, and had some broad agreement
<MarkMccarthy> Matt_King: but there was one issue [rummaging for issue]
<jongunderson> https://github.com//issues/1228
<MarkMccarthy> carmacleod: Matt_King, you said we should mention what aria-at is planning to provide and that might be a good note?
<MarkMccarthy> Matt_King: so, after reading what's in that issue and discussing what's -not- clear about the 1150 note, i started drafting an alternative to make it more specific
<MarkMccarthy> Matt_King: i think we might need something different. i'll copy it into the minutes
<Matt_King> Matt's proposed wording for issue 1150 note: Because an API for capturing interaction events generated by touch-based assistive-technologies is not yet available, some interactions necessary for this pattern to be fully accessible with touch based assistive technologies are not supported. Authors should fully test this widget with assistive technologies before using it for a production ready...
<Matt_King> ...project.
<MarkMccarthy> carmacleod: [reading above text]
<MarkMccarthy> carmacleod: this is only touch, right?
<MarkMccarthy> Matt_King: exactly, because there's a few examples that can't be made usable without listening for certain event
<MarkMccarthy> s/event/events
<MarkMccarthy> jongunderson: like spinbutton?
<MarkMccarthy> Matt_King: well, there's ways. but what -will- happen is AT may tell you it's adjustable, but they might not work. could be confusing, but that might be it
<MarkMccarthy> Matt_King: i'm not opposed to adding it for spinbutton though
<MarkMccarthy> carmacleod: it is different. I think Mark's was simpler and easier to understand
<MarkMccarthy> Matt_King: wondering if we should remove the "authors should test..." text
<MarkMccarthy> Matt_King: it's not fixable, there's nothing to test
<MarkMccarthy> carmacleod: true!
<MarkMccarthy> carmacleod: re-reading yours though, Matt, it seems fine
<MarkMccarthy> Matt_King: I thought it needed to be more specific because there's a difference in an example not being workable via touch AT because of a bug or because of a bug in the pattern
<MarkMccarthy> Matt_King: but this is saying it's essentially impossible without an API
<MarkMccarthy> Matt_King: didn't want people confused about why that note isn't in more places
<MarkMccarthy> Matt_King: other thoughts?
<MarkMccarthy> jongunderson: i think it describes well what the primary issue is, being lack of API support
<MarkMccarthy> jongunderson: so this would only go on those specific examples?
<MarkMccarthy> Matt_King: yeah
<MarkMccarthy> jongunderson: what about comboboxes?
<MarkMccarthy> Matt_King: zcorpan is working on rearraging some things, so that might be addressed then
<MarkMccarthy> jamesn: any chance that can be done before 1.2?
<MarkMccarthy> jamesn: thought that was ready?
<MarkMccarthy> Matt_King: well let's close on warning text. i'm gonna add this to the PR and request some reviews. we'll go from there
<MarkMccarthy> Matt_King: carmacleod, can you draft a PR for the support note?
<MarkMccarthy> carmacleod: I can do that
<MarkMccarthy> carmacleod: let's agree on words before formalizing a PR
<MarkMccarthy> Matt_King: placement and styling as well
<MarkMccarthy> carmacleod: yes
<MarkMccarthy> Matt_King: so we'll add this to agenda next week

[carmacleod]

Compromise between Matt's wording and Mark's wording:

Warning
Interaction with widgets implemented using this pattern may not be fully supported by touch-based assistive technologies because an API for capturing touch-based interaction events is not yet available. Authors should fully test this widget with assistive technologies before using it for a production ready project.

[carmacleod]

Which widgets should this warning go on?
The following roles are mentioned in issue #8 and issue #1150:

• slider
• tree
• menu (i.e. for submenus)
• spinbutton

[JAWS-test]

I tested only the slider pattern with TalkBack and Voiceover. Both screen readers do not work with slider on the smartphone

[mcking65]

@carmacleod wrote:

Which widgets should this warning go on?
The following roles are mentioned in issue #8 and issue #1150:

• slider
• tree
• menu (i.e. for submenus)
• spinbutton

For sure slider and multi-thumb slider.

Some sppin-button implementations can be made to work if they use the structure where increment/decrement buttons are outside the button. We have that in our example.

Menus can be made fully accessible on mobile without any additional APIs.

I am unsure of tree. I don't see why mobile Safari and Chrome could not enable trees to be fully accessible without any additional tree-specific gestures. It seems to me that swipe left/right and double tap are enough to make a tree work. However, that wouldn't make the tree experience great; it would have none of the usability advantages that trees provide on desktop. The last time I looked at trees in iOS or Android (years ago), the main problem seemed to be either a lack of mappings in the browser or support for the mappings by the screen readers.

[carmacleod]

+1

[JAWS-test]

Some sppin-button implementations can be made to work if they use the structure where increment/decrement buttons are outside the button. We have that in our example

The slider pattern could also be made accessible for touch devices by adding two buttons to increase and decrease the value or an input field to enter the value

[JAWS-test]

Tree

I have tested https://www.w3.org/TR/wai-aria-practices-1.1/examples/treeview/treeview-1/treeview-1a.html with Talkback (Chrome) and VoiceOver (Safari) and the tree works well with both screenreaders on the smartphone without keyboard. The only problem: The hierarchy of the treeitems is not output.

Note: The following small problem occurs in every browser: in the input field "File or Folder Selected" after selecting a folder not the name of the folder is displayed, but the entire HTML code including all child elements (<span class="focus">Reports</span><ul role="group">...)

Menubar

I have also tested https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html on the same smartphones:

• Talkback: Operation works fine without a keyboard
• Voiceover: I couldn't open the submenus without keyboard (but maybe there is a gesture I don't know and it would work with)

Regardless of Talkback, there is a problem with Chrome (Android) in the menu bar: The menu entries are displayed much smaller than the rest of the page. But when I open a submenu, the menu items are displayed large and the page scrolls up so that the menu is not visible. The problem does not occur with Firefox (Android).

[carmacleod]

Thank-you, @JAWS-test - that's useful information.

It would seem that we may need the "mobile support gap warning" for menu/submenu as well.

Regarding the TreeView problem that you noted, I've created PR #1306 to fix it.

We may need to open a separate issue for the submenu size & scroll problem.

[JAWS-test]

Menu

I think, the menu could be designed accessible if the submenus could be opened and closed with a click (just add a click eventhandler)

We may need to open a separate issue for the submenu size & scroll problem.

See: #1307

Tree

I think we need a warning for tree. The examples in ARIA APG work because they are simple. The multi-selection trees described at https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView may not work on mobile devices with a screen reader, because the screen reader can only pass the simple click events, if I understand correctly.

[mcking65]

@JAWS-test, thank you for the additional testing and information.

As suggested earlier, your findings seem to confirm that we do not need AOM to make menus work with touch-based assistive technologies. The same is probably true for single-select trees. You raise a good question about multi-select trees.

This pull request will add the approved warning only to the slider patterns. Before closing issue #1150, we should make a final decision about whether or not it is appropriate to add this warning to the tree pattern. I have added this to my draft of the February 4 meeting agenda.

[JAWS-test]

As suggested earlier, your findings seem to confirm that we do not need AOM to make menus work with touch-based assistive technologies

I'm not sure that's true. With Safari+iOS and VoiceOver I couldn't open the submenus. It would be good if someone with more experience could check it out

[a11ydoer]

@JAWS-test

I tested only the slider pattern with TalkBack and Voiceover. Both screen readers do not work with slider on the smartphone

Would you kindly retest revised ARIA APG slider example with Talkback and Voiceover?

Github issue is 1746. It also includes mobile testing info by others.

[JAWS-test]

@a11ydoer: Unfortunately, I no longer have an Apple device for the Voiceover test. Talkback I can test, but am currently very busy professionally and do not know yet when I will manage it. However, I saw that you and @patrickhlauke have already tested. That should be sufficient, right?