IOS Accessibility Issues

From Level Access Web Labs
Revision as of 05:33, 10 November 2017 by Oedwards (talk | contribs) (List of iOS accessibility issues: Note that VoiceOver issue with role="dialog" is not fixed in iOS 11.0.)
Jump to navigation Jump to search

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

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