Known OS/Browser/AT Issues
When describing known issues, be sure to note the version of OS, browser and AT where the issue can be reproduced. It is not necessary for the original reporter to determine if the issue affects other versions of OS/Browser/AT, but notes can be added by others if the issue is found in other versions. Also, notes should be added if it is observed that the issue is not present in another version of OS/Browser/AT.
Digital A11y has a helpful resource on "How & Where to report accessibility bugs (in browsers, operating systems, and assistive technology software)", which can also be used as a resource on where to look up existing/known accessibility bugs with those products.
- 1 Windows and ...
- 2 MacOS and ...
- 3 iOS
- 4 Android
- 5 Windows 10 Phone
- 6 Aria-describedby Support
- 7 Bug Reporting to Vendors
Windows and ...
- In IE 11, with JAWS 2018 in auto forms mode, when a user tabs to a link that has the appropriate ARIA for a menu button, then the href value of the link is added to the JAWS announcement.
- In IE 11, with JAWS version 18.0.2118 and 18.0.2324, when a user tabs to a link element, aria-expanded value as collapsed or expanded is not announced. However, navigating in virtual cursor announces the aria-expanded value. Please note, this works fine in JAWS 17.0. This also affects buttons that have aria-expanded.
- The link results with 18.0.2324 may be inconsistent, as I (MikeS) have a case where 18.0.2324 fixed the problem with links that 18.0.2118 had, but Mansi said 18.0.2324 still exhibits the problem.
- JAWS 18 (tested 18.0.2118) now supports the new aria-current, where JAWS 17 did not.
- JAWS 18 (tested 18.0.2118) supports aria-posinset and aria-setsize for widgets like tabs and listboxes, where 17 did not.
- JAWS 18 (tested 18.0.2118 and 18.0.2324) - self referential aria-labelledby attributes with multiple tokens (See Self Referential aria-labelledby) cause JAWS to announce the self-referential id token once, and all other tokens twice. Issue is not encountered with JAWS 17.
- JAWS 16 had some problems announcing ARIA live region updates, problems that did not occur in v.15 and that were generally fixed in v.17.
- In IE when navigating to an ARIA Slider in virtual Cursor mode after Forms mode has been activated nothing is announced JAWS 18 IE 11 Labs ARIA Slider
- ARIA spin buttons The role is not announced when navigating in virtual cursor mode using the arrow keys in Internet Explorer.
- In some cases when adjusting the value of an aria spin button JAWS announces blank in Internet Explorer. http://oaa-accessibility.org/example/33/
- NVDA 2016.4 does not yet support the new aria-current. This was fixed in NVDA 2017.2
- NVDA 2016.4 double-read when a homegrown ARIA Listbox was opened after activating its triggering toggle button. It read: "Select a frequency. List. Once. 1 of 6. Select a frequency. List. Once. 1 of 6."
- NVDA 2017.1 ARIA List Box List items are announced in Browse mode in Internet Explorer when navigating with the ARROW keys. In Internet Explorer, navigate to ARIA list Box lab page Navigate to the Platform Label. Press DOWN ARROW Notice that NVDA announces the list items iOS, Android, Windows Phone. According to bug 6934 this should not be the case. (6965)
- NVDA with Firefox recognizes a link with a child <svg> as a link, but the text within the <title> element of the <svg> is not announced. NVDA announces the path within the href attribute only. Pointing to the <title> via aria-labelledby does not cause it to be announced, either. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- When using <input type="number">, the field appears as unlabeled in NVDA's element list.
Dragon Naturally Speaking
- When using <input type="number">, the field cannot be dictated or selected.
- The <svg> element inside a focusable element (like a link or button) in Internet Explorer defaults to focusable="true" due to a bug. This causes both the parent element and the <svg> to receive focus. The focus indicator disappears when the image file receives focus, and some screen readers read the content twice since parts of it get focus twice. The way to fix this is to add focusable="false" to the <svg> to set the attribute to what it should be by default. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- Internet Explorer 8 and below will visually render the content found in <desc>…</desc> tags inside <svg> elements. A conditional can be used to hide this from old Internet Explorer versions. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
Firefox (on Windows)
- Use Firefox 61+ with JAWS 2018 May Update+ (or NVDA 2018.3+). When older versions of JAWS or NVDA must be used, use Firefox 56 or the 'ESR' release of Firefox, version 52.x.
With JAWS 2018 and 2019 a blank virtual buffer is rendered for google forms and google docs. this is reported at https://github.com/FreedomScientific/VFO-standards-support/issues/136
Chrome (on Windows)
- Clip method for offscreen text causing issues concatenating words in Chrome
- In some cases, strong or em elements are omitted from accessible name calculation: Chromium bug #1047549 This is fixed in Chrome 81.
- No keyboard support for making non-contiguous selections in <select multiple> element (combo box) in Chrome (see Chromium Issues 90172, 982450, and 939526).
- Datepicker inputs: cannot access button to open calendar settings using the keyboard. (907297)
John and James Dietz couldn't find this button. Seems like a pretty minor issue, since values can be modified using the up/down arrow keys with the keyboard. Roy thinks this is fixed in chrome 83. The Date picker was used at Input Element Multiple Types
- Multiple updates to a single aria-live region will not be spoken. (863375)
This issue is more significant. An aria-live region which is updated with "Search results displayed" when a search is completed will be updated again with the same text once the search is cleared and a new search is entered. This update will not be received by ATs using Chrome This works as expected in Firefox. See also the Google Docs example on the bug's page. Roy tested this in Chrome 80 on 4/6/2020 and believes it is fixed. the live region text was repeated.
- [NVDA Only] Bug with NVDA and aria menu with nested role=menuitemcheckbox demonstrated in Gmail settings page (974266) This bug is marked as fixed.
- Longdesc not exposed to assistive technologies (224287)
- "has autocomplete" not announced for form fields that chrome has saved histories for (994904)
Note that this bug has to do with the native browser autocomplete functionality, not custom autocomplete fields.
- Issue with rowspan in an HTML table is just not playing well with JAWS (2020, 2019, 2018) when using Chrome (version 79). When moving down a column, the virtual cursor moves diagonally.
- For example, Example 2: Table with headers spanning multiple rows or columns <https://www.w3.org/WAI/tutorials/tables/irregular/#table-with-headers-spanning-multiple-rows-or-columns>
MacOS and ...
- When an <img> tag is used with an .svg as the source, VoiceOver with Safari will read the alt value but does not identify the image as such without role="img", and the image doesn’t show up in the image list in the rotor. If the image is implemented as link content, the content is read as link text but does not identify as an image, without the role. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- aria-label attributes applied to <svg> elements are skipped by VoiceOver with Safari unless the <svg> is a child of a focusable element. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- When accessed in Safari 10, <svg> elements that have <use> elements without whitespace between the parent <svg> and child <use> tags prevent focus from moving past the <svg>. Adding whitespace around the <use> tags fixes this. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- Intermittently, the swipe right gesture causes focus to move to the element under the user's finger where they swiped. This issue has been observed in Android OS version 6, with Nexus and Samsung devices. The issue has not been observed in Android OS version 7.
- TalkBack with Chrome and Firefox will identify an <img> with an .svg as the source as an image without role="img", unless it’s part of a link. Then, the alt value is identified as the link text, but no image is mentioned. (March 2017, https://simplyaccessible.com/article/7-solutions-svgs/)
- TalkBack 7.3 (Android OS 9, in Chrome) in its 'Default' gesture setting does not announce all of the role information in accordions that are implemented as expandable buttons within headings and whose expanded contents are rendered in named regions. The expandable buttons are announced (the most important part), but the additional role of heading (and level) and the named region are not announced at all. In contrast, VoiceOver in iOS and JAWS announce both heading and button roles when the accordion element gains focus, as well as the region. TalkBack announces headings and regions when they are by themselves, or announces the headings in the accordions if the navigation mode is changed to Headings, though of course then the buttons are not announced. Further testing is needed to corroborate and clarify the bounds of this finding before considering filing a defect, but this would impose a significant compatibility/support issue with teh generally-recommended accordion implementation for us and the ARIA 1.1 APG. [MikeS]
The WebAIM screen reader survey said, regarding mobile screen readers (https://webaim.org/projects/screenreadersurvey8/#mobilescreenreaders) that Voice Assistant had a 8.2% usage among mobile screen readers, compared to 33.0% for TalkBack. So even though the user would have to get TalkBack manually, and Samsung Galaxy phones are market share leaders, Voice Assistant is little-used - but it is used by some.
- In an extensive client project, differences between Voice Assistant and TalkBack were observed but the details may not have been captured. If time permits, some of that project's raw data or notes should be mined to identify these differences and weaknesses.
- The use of aria-disabled on static text () causes Voice Assistant to not read the static content, what aria-hidden="true" would normally do. That aria-disabled seems inappropriate to put on static text that can never be "enabled" leaves open the question of how well Voice Assistant has implemented ARIA support for valid, common uses of ARIA.
- Firefox version 5x - add information about the latest big problem forcing us to downgrade - or use Chrome.
- Firefox version 53 (any earlier versions too?): Firefox reports HTML and ARIA checkboxes as buttons. This should be fixed in Firefox 54.
- Firefox versions 43 through 46: had a severe problem that prevented TalkBack users from being able to activate links. For much of 2016 until v.47 fixed the problem, we deliberately downgraded Firefox to v.42 to avoid this problem.
Android browser (not Chrome)
Question: Does this refer to the old "Browser" or to the "Samsung Internet Browser" that apparently comes as the default browser on newer Galaxy devices (so new we may be lucky if we have one such device)?
Windows 10 Phone
Some AT/Browser combinations have support issues with aria-describedby. The link below documents known combinations that lack support.
Bug Reporting to Vendors
- Mozilla: https://bugzilla.mozilla.org/
- Freedom Scientific/VFO:
- VFO Standards Support issues
- A few Level Access employees have been granted access to their bug-tracking system, including (confirm) Jon, Bryan, Roy, possibly Doug.
- Microsoft: https://microsoftaccessibility.uservoice.com/forums/307429-microsoft-accessibility-feedback
- NVDA: https://github.com/nvaccess/nvda/issues