Slider patterns: Provide warning about inability to operate with touch-based assistive technologies due to lack of needed APIs #1186
Conversation
|
Words look good! For others' convenience, here's a direct link, and a copy of the warning paragraph:
|
|
Updated warning based on 10/1 call feedback (thank you). It now reads:
If I misunderstood (which is possible) please make a comment. |
|
The ARIA Authoring Practices (APG) Task Force just discussed 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 |
|
Compromise between Matt's wording and Mark's wording:
|
|
Which widgets should this warning go on?
|
|
I tested only the slider pattern with TalkBack and Voiceover. Both screen readers do not work with slider on the smartphone |
|
@carmacleod wrote:
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. |
c035434 to
Compare
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 |
TreeMenubar |
|
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. |
MenuI think, the menu could be designed accessible if the submenus could be opened and closed with a click (just add a click eventhandler)
See: #1307 TreeI 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.
4eb8671 to
Compare
|
@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 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]>
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 |
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. |
|
@patrickhlauke have already tested. That should be sufficient, right? |
Partially resolves issue #1150 by adding a warning to the slider patterns.
Diff