You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 5, 2024. It is now read-only.
Repository navigation
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
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.
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.
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
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.
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
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.
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!
Activity
pieman72 commentedon Feb 22, 2018
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.
[-]Links inside md-checkboxes are not accessible[/-][+]checkbox: links in text are not rendered in an accessible way[/+]Splaktar commentedon Feb 26, 2018
I enhanced the CodePen a bit for me to test with. This included adding a
formandng-modelso thataria-checkedwould 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.
[-]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[/+]pieman72 commentedon Feb 26, 2018
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).
Splaktar commentedon Feb 27, 2018
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 withinlabelelements 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 usingariaattributes and see if we can come up with a non-breaking way of solving this.pieman72 commentedon Feb 27, 2018
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!
10 remaining items
fix(checkbox): handle links in transcluded label in an a11y-friendly way
fix(checkbox): handle links in transcluded label in an a11y-friendly way
fix(checkbox): handle links in transcluded label in an a11y-friendly way
Splaktar commentedon Mar 29, 2018
As this change is a breaking change, I've pushed it to 1.2.0. More details in #11154 (comment).
fix(checkbox): handle links in transcluded label in an a11y-friendly way
fix(checkbox): handle links in transcluded label in an a11y-friendly way
fix(checkbox): handle links in transcluded label in an a11y-friendly way