Skip to content
This repository was archived by the owner on Sep 5, 2024. It is now read-only.
This repository was archived by the owner on Sep 5, 2024. It is now read-only.

checkbox: links in text are not rendered in a way that makes JAWS happy #11134

Closed

Description

@pieman72

Bug, feature request, or proposal:

Bug

What is the expected behavior?

A link (<a href="...">) nested inside an <md-checkbox ...> element should be recognized as a link by screen readers such as JAWS. This entails being accessible via screen reader specific navigation shortcuts (U and V keys for JAWS), and upon receiving focus it should be announced that the focused element is a link.

What is the current behavior?

Such links are not accessible via shortcut keys, and are not announced as links.

CodePen and steps to reproduce the issue:

CodePen Demo] which shows your issue:

https://codepen.io/anon/pen/VQdGBX

Detailed Reproduction Steps:
  1. Enable JAWS prior to enabling Firefox
  2. Open Firefox and activate the JAWS screen reader
  3. Visit a page containing a <a> inside a <md-checkbox> (such as the CodePen example linked above)
  4. Use the U (unvisited link) key to browse through the not visited links with JAWS (use V key if link was visited before)
  5. Verify that the link inside the md-checkbox is reachable
  6. Using the TAB key, place the focus on that same link
  7. Listen to the screenreder's audio feedback, and Verify that the screen reader announces that a link is focused

What is the use-case or motivation for changing an existing behavior?

A11y - Currently, a standard practice (placing links inside a checkbox label) results in an inaccessible page.

Which versions of AngularJS, Material, OS, and browsers are affected?

Angular 1.6
Material 1.1
Windows 10 Enterprize
Firefox 52.6.0 ESR
JAWS 2018 (1712 10 ILM), NVDA 2017.4

Is there anything else we should know? Stack Traces, Screenshots, etc.

The HTML output by Angular results in the following accessibility tree:

checkbox "I agree to the privacy policy"

GenericContainer

link "privacy policy"

text "privacy policy"

I suspect a link typically should be inside a label, not nested directly within the checkbox.

Activity

  1. pieman72 commented on Feb 22, 2018

    @pieman72
    Author

    Likely as a side effect of this, the text in the link is voiced twice by the screen reader. When there is no link, the content of the checkbox is "ignored" in the accessibility tree.

  2. added
    a11yThis issue is related to accessibility
    needs: investigationThe cause of this issue is not well understood and needs to be investigated by the team or community
    on Feb 26, 2018
  3. self-assigned this
    on Feb 26, 2018
  4. changed the title [-]Links inside md-checkboxes are not accessible[/-] [+]checkbox: links in text are not rendered in an accessible way[/+] on Feb 26, 2018
  5. Splaktar commented on Feb 26, 2018

    @Splaktar
    Contributor

    I enhanced the CodePen a bit for me to test with. This included adding a form and ng-model so that aria-checked would be set properly. Using ChromeVox on macOS, I don't really see any significant problems.

    I will try to do some more testing using VoiceOver and Safari.

  6. changed the title [-]checkbox: links in text are not rendered in an accessible way[/-] [+]checkbox: links in text are not rendered in a way that makes JAWS happy[/+] on Feb 26, 2018
  7. added
    P4: minorMinor issues. May not be fixed without community contributions.
    on Feb 26, 2018
  8. added this to the 1.1.9 milestone on Feb 26, 2018
  9. pieman72 commented on Feb 26, 2018

    @pieman72
    Author

    The issue does not manifest itself in ChromeVox (neither in your example nor in mine), but it does occur in JAWS (at least on Firefox on Windows).

  10. added
    g3: reportedThe issue was reported by an internal or external product team.
    P3: importantImportant issues that really should be fixed when possible.
    and removed
    P4: minorMinor issues. May not be fixed without community contributions.
    on Feb 26, 2018
  11. Splaktar commented on Feb 27, 2018

    @Splaktar
    Contributor

    We currently parse everything inside of the <md-checkbox>here</md-checkbox> into <span> elements with other HTML elements preserved.
    I.e. <span>Please accept</span><a href="blah">privacy policy</a><span>.</span>
    This seems like it would clearly cause some extra screen reader output.

    My research into more a11y-friendly/normal implementations would use:
    <label for="cb"><input id="cb" type="checkbox">Please accept the <a href="blah">privacy policy</a></label>. Links within label elements seem to be within the standards. Angular Material does this.

    However moving to the label/native input method would be a breaking change. We're going to try to solve this by testing without the <span> elements or using aria attributes and see if we can come up with a non-breaking way of solving this.

  12. pieman72 commented on Feb 27, 2018

    @pieman72
    Author

    Understood. I agree with the "normal implementation" you described, but understand that it would be a breaking change. Your proposed alternative sounds good to me, thanks!

  13. 10 remaining items

  14. added 3 commits that reference this issue on Mar 12, 2018
    79f3d96
    212d940
    9882de3
  15. modified the milestones: 1.1.8, 1.1.9 on Mar 17, 2018
  16. modified the milestones: 1.1.9, 1.2.0 on Mar 29, 2018
  17. Splaktar commented on Mar 29, 2018

    @Splaktar
    Contributor

    As this change is a breaking change, I've pushed it to 1.2.0. More details in #11154 (comment).

  18. added 2 commits that reference this issue on Jun 30, 2020
    a8b31bd
    16fdc61
  19. added a commit that references this issue on Jun 30, 2020
    4d36fd2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

- Breaking ChangeP3: importantImportant issues that really should be fixed when possible.a11yThis issue is related to accessibilityg3: reportedThe issue was reported by an internal or external product team.has: Pull RequestA PR has been created to address this issueresolution: fixed

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions