Difference between revisions of "IOS Accessibility Issues"

From Level Access Web Labs
Jump to navigation Jump to search
Line 10: Line 10:
 
* Radio buttons all being announced as "1 of 1" rather than the correct "x of y": This may have been fixed or at least improved as a test page that elicited this problem with iOS 9.3.5 works fine with iOS 10.2.1. This has been a long-time observation or tendency in VoiceOver. The following article http://stackoverflow.com/questions/37416680/how-to-get-voiceover-screen-reader-to-work-with-radio-buttons-to-say-proper-num seemed to pin the problem on VoiceOver "hitting a wall" when it encountered display:block, and the first responder (heh) claimed that changing display:block to display:inline-block would fix it, and the original poster confirmed the fix. However, testing suggested that this only improved but did not fix the problem in iOS 9.3.5. With display:block, all 3 radio buttons were "1 of 1"; with display:inline-block, the first radio button was "1 of 1" while the second and third ere "1 of 2" and "2 of 2". But VO in iOS 10.2.1 announces the correct X of Y using either CSS value. This should not be taken as proof that iOS 10.2.1 (or whatever prior version of 10.x) fixed the problem across the board, but it's certainly hopeful. Additional testing that confirms or contradicts these results should be entered here. The stackoverflow's sample form can be used for testing, or the following mimics it: https://labs.ssbbartgroup.com/index.php/MikeS_VO_1of1
 
* Radio buttons all being announced as "1 of 1" rather than the correct "x of y": This may have been fixed or at least improved as a test page that elicited this problem with iOS 9.3.5 works fine with iOS 10.2.1. This has been a long-time observation or tendency in VoiceOver. The following article http://stackoverflow.com/questions/37416680/how-to-get-voiceover-screen-reader-to-work-with-radio-buttons-to-say-proper-num seemed to pin the problem on VoiceOver "hitting a wall" when it encountered display:block, and the first responder (heh) claimed that changing display:block to display:inline-block would fix it, and the original poster confirmed the fix. However, testing suggested that this only improved but did not fix the problem in iOS 9.3.5. With display:block, all 3 radio buttons were "1 of 1"; with display:inline-block, the first radio button was "1 of 1" while the second and third ere "1 of 2" and "2 of 2". But VO in iOS 10.2.1 announces the correct X of Y using either CSS value. This should not be taken as proof that iOS 10.2.1 (or whatever prior version of 10.x) fixed the problem across the board, but it's certainly hopeful. Additional testing that confirms or contradicts these results should be entered here. The stackoverflow's sample form can be used for testing, or the following mimics it: https://labs.ssbbartgroup.com/index.php/MikeS_VO_1of1
 
* it is not possible to adjust the ARIA slider in iOS [https://labs.ssbbartgroup.com/index.php/ARIA_Slider_-_Horizontal Aria Slider]
 
* it is not possible to adjust the ARIA slider in iOS [https://labs.ssbbartgroup.com/index.php/ARIA_Slider_-_Horizontal Aria Slider]
* Anna found major problems with <select> elements that contain <optgroup> groupings. Anna to enter details here.  
+
* The <select> elements that contain <optgroup> groupings are not read properly on iOS 11.2.6 on Safari Browser. When VoiceOver reads the optgroup label which are read as headings, it is assumed as a regular picker option. Thus, users cannot understand the structure of the listbox. The user cannot trigger the option using the done button. No option is selected after the user use the swipe up or down on the picker, then done button. If the user use double tap to trigger the option on the optgroup, the picker container is left on the screen and done button must be pressed to remove the picker container on the page.
  
 
==Bug-tracking==
 
==Bug-tracking==

Revision as of 20:32, 14 March 2018

List of iOS accessibility issues

  • Picker control (the control which is displayed when a <select> element is present on a web page, for example): focus does not return properly from picker control in web content
    • Present in iOS 9.x, changed but not fixed in 10.1
    • This also appears to affect the on-screen keyboard when you either tap the Done button on iPhone or tap the close keyboard button on iPad. Focus is not returned to the field in which you were just typing with the OSK.
  • Bug 161118 – AX: VoiceOver on iOS ignores aria-checked on menuitemradio and menuitemcheckbox https://bugs.webkit.org/show_bug.cgi?id=161118
  • AX: ARIA tree & treeitem roles & aria-expanded state not spoken to VoiceOver iOS 10
  • iOS 10.0 broke support for links' use of aria-labelledby and aria-label, and it remains broken in 10.2. From 9/26/16 WebAIM post from Paul Adam found by Jon. Test file given is http://pauljadam.com/demos/linkpurpose.html. VO in 10.x announces links' inner text but fails to announce aria-labelledby or aria-label when present in these links, though it does announce aria-describedby correctly.
  • iOS 10's support for role=dialog has changed, with "good news and bad news". Good news: the dialog is treated as a landmark and its boundaries are announced (web dialog / end web dialog). The (very) bad news is that adding aria-modal="true" breaks the reading of the dialog and prevents access to the rest of the page. That was tested by adding aria-modal="true" to the dialog in https://labs.ssbbartgroup.com/index.php/ARIA_Dialog_Role, and on https://labs.ssbbartgroup.com/index.php/Modal_dialog_with_ARIA. This is not fixed in iOS 11.0 (Get further info from prior email thread and add here.)
  • Radio buttons all being announced as "1 of 1" rather than the correct "x of y": This may have been fixed or at least improved as a test page that elicited this problem with iOS 9.3.5 works fine with iOS 10.2.1. This has been a long-time observation or tendency in VoiceOver. The following article http://stackoverflow.com/questions/37416680/how-to-get-voiceover-screen-reader-to-work-with-radio-buttons-to-say-proper-num seemed to pin the problem on VoiceOver "hitting a wall" when it encountered display:block, and the first responder (heh) claimed that changing display:block to display:inline-block would fix it, and the original poster confirmed the fix. However, testing suggested that this only improved but did not fix the problem in iOS 9.3.5. With display:block, all 3 radio buttons were "1 of 1"; with display:inline-block, the first radio button was "1 of 1" while the second and third ere "1 of 2" and "2 of 2". But VO in iOS 10.2.1 announces the correct X of Y using either CSS value. This should not be taken as proof that iOS 10.2.1 (or whatever prior version of 10.x) fixed the problem across the board, but it's certainly hopeful. Additional testing that confirms or contradicts these results should be entered here. The stackoverflow's sample form can be used for testing, or the following mimics it: https://labs.ssbbartgroup.com/index.php/MikeS_VO_1of1
  • it is not possible to adjust the ARIA slider in iOS Aria Slider
  • The <select> elements that contain <optgroup> groupings are not read properly on iOS 11.2.6 on Safari Browser. When VoiceOver reads the optgroup label which are read as headings, it is assumed as a regular picker option. Thus, users cannot understand the structure of the listbox. The user cannot trigger the option using the done button. No option is selected after the user use the swipe up or down on the picker, then done button. If the user use double tap to trigger the option on the optgroup, the picker container is left on the screen and done button must be pressed to remove the picker container on the page.

Bug-tracking

Safari related VoiceOver/iOS bugs should be logged on the Webkit bugzilla page. Bookmark this short URL: http://webkit.org/new-ax-bug

Here’s the list of all open WebKit AX bugs: https://bugs.webkit.org/buglist.cgi?list_id=625399&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Accessibility&product=WebKit

Misc.

In addition to WebAIM posts, Jon also suggested Twitter is a good place to look for others #ios10 #a11y He also suggested that applevis.com is a good place to look for what iOS 10 might have fixed/improved in VO.

Third-Party Issues

The unsupported FastClick.js has been found to create major unreliability in VoiceOver's (10.x at least) ability to activate links (at least). Its purpose of removing the 300ms delay for touch events has evidently outlived its usefulness anyway and we recommend clients remove it from their mobile/responsive websites. (More details are in internal email exchanges from early August 2017. Can add some of that here, but in the meantime, ask Jon or Mike or MItchell or a few others.)