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

charmarkk · 2019-09-24T19:17:02Z

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

carmacleod · 2019-09-24T19:53:58Z

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 · 2019-10-03T01:24:59Z

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 · 2019-11-05T19:35:05Z

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 · 2020-01-14T18:50:31Z

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 · 2020-01-20T17:46:43Z

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 · 2020-01-20T19:11:00Z

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

mcking65 · 2020-01-21T18:31:13Z

@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.

aria-practices.html

carmacleod

+1

JAWS-test · 2020-01-22T05:08:21Z

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 · 2020-01-23T19:37:36Z

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 · 2020-01-24T02:34:41Z

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 · 2020-01-24T07:16:35Z

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.

…pecific and actionable.

mcking65 · 2020-01-27T06:53:41Z

@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.

Slider patterns: Provide warning about inability to operate with touch-based assistive technologies due to lack of needed APIs (pull #1186) Addresses issue #1150 for the slider patterns by adding a warning. The warning explains that widgets using the pattern are not fully operable with touch-based assistive technologies because the needed APIs do not yet exist. Co-authored-by: Matt King <[email protected]> Co-authored-by: Carolyn MacLeod <[email protected]>

JAWS-test · 2020-01-27T13:24:59Z

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 · 2021-03-02T20:30:25Z

@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 · 2021-03-03T06:30:34Z

@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?

css-meeting-bot mentioned this pull request Oct 1, 2019

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

Closed

charmarkk marked this pull request as ready for review October 9, 2019 15:43

ZoeBijl mentioned this pull request Oct 22, 2019

Guidance for touch devices #8

Open

ZoeBijl approved these changes Nov 11, 2019

View reviewed changes

carmacleod reviewed Jan 21, 2020

View reviewed changes

aria-practices.html Outdated Show resolved Hide resolved

mcking65 force-pushed the issue1150-provide-warning-for-support-gaps branch from c035434 to d688881 Compare January 21, 2020 18:42

carmacleod approved these changes Jan 22, 2020

View reviewed changes

carmacleod mentioned this pull request Jan 24, 2020

Tree Examples: Correct result of selecting parent node #1306

Merged

carmacleod mentioned this pull request Jan 25, 2020

Stronger support / testing / best practices text on every example #1228

Closed

charmarkk and others added 10 commits January 26, 2020 22:21

Added draft warning to slider widget pattern

51e4374

Added h4 to warning section

a40136a

moved warning, changed to note

b3ec4ef

moved warning

c2415a9

cleaned up warning

72d9b46

changed slider warning based on 9-24 call feedback

95092f8

made changes based on 10/1 feedback, Zoe's suggestion

55609b1

Revise wording based on latest discussion to make the guidance more s…

e29ab6e

…pecific and actionable.

fix typo

1b17233

Add warning to multi-thumb slider pattern

766ce61

mcking65 force-pushed the issue1150-provide-warning-for-support-gaps branch from 4eb8671 to 766ce61 Compare January 27, 2020 06:22

mcking65 changed the title ~~Issue1150 provide warning for support gaps~~ Slider patterns: Provide warning about inability to operate with touch-based assistive technologies due to lack of needed APIs Jan 27, 2020

mcking65 merged commit eec5af6 into master Jan 27, 2020

mcking65 deleted the issue1150-provide-warning-for-support-gaps branch January 27, 2020 06:57

Clemens-git76 mentioned this pull request Apr 16, 2024

[Snyk] Upgrade eslint-plugin-jsdoc from 39.3.3 to 48.2.1 Clemens-git76/aria-practices#1

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

charmarkk commented Sep 24, 2019 •

edited by pr-preview bot

Loading

carmacleod commented Sep 24, 2019

charmarkk commented Oct 3, 2019

css-meeting-bot commented Nov 5, 2019

carmacleod commented Jan 14, 2020

carmacleod commented Jan 20, 2020

JAWS-test commented Jan 20, 2020

mcking65 commented Jan 21, 2020

carmacleod left a comment

JAWS-test commented Jan 22, 2020

JAWS-test commented Jan 23, 2020 •

edited

Loading

carmacleod commented Jan 24, 2020 •

edited

Loading

JAWS-test commented Jan 24, 2020 •

edited

Loading

mcking65 commented Jan 27, 2020

JAWS-test commented Jan 27, 2020

a11ydoer commented Mar 2, 2021

JAWS-test commented Mar 3, 2021 •

edited

Loading

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

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

Conversation

charmarkk commented Sep 24, 2019 • edited by pr-preview bot Loading

carmacleod commented Sep 24, 2019

charmarkk commented Oct 3, 2019

css-meeting-bot commented Nov 5, 2019

carmacleod commented Jan 14, 2020

carmacleod commented Jan 20, 2020

JAWS-test commented Jan 20, 2020

mcking65 commented Jan 21, 2020

carmacleod left a comment

Choose a reason for hiding this comment

JAWS-test commented Jan 22, 2020

JAWS-test commented Jan 23, 2020 • edited Loading

Tree

Menubar

carmacleod commented Jan 24, 2020 • edited Loading

JAWS-test commented Jan 24, 2020 • edited Loading

Menu

Tree

mcking65 commented Jan 27, 2020

JAWS-test commented Jan 27, 2020

a11ydoer commented Mar 2, 2021

JAWS-test commented Mar 3, 2021 • edited Loading

charmarkk commented Sep 24, 2019 •

edited by pr-preview bot

Loading

JAWS-test commented Jan 23, 2020 •

edited

Loading

carmacleod commented Jan 24, 2020 •

edited

Loading

JAWS-test commented Jan 24, 2020 •

edited

Loading

JAWS-test commented Mar 3, 2021 •

edited

Loading