brea11y
commented
4 months ago Hey guys!
- How does a screen reader behave in web around hyperlinks within a paragraph?
- Each screen reader is different, but they typically behave / should behave very similarly to a standalone CTA link. When a screen reader tabs to the link / gets to the link, it should say "link [copy of the link]". So, if the link within the copy said "2018 Winter Olympics", for example, the screenreader would say "link, 2018 winter olympics". Some screen readers will may read the entire text block including the link and identify the link while it reads out, while others (like VoiceOver) may read the preceding text, then the link, and so on.
- Is the Android behavior good?
- Yes, the Android behavior looks and sounds great to me. I like the announcement at the conclusion of the paragraph that tells the user that there are links within the content. I also like that when you navigate to the individual links, they say "link" at the end. That announcement would be fine at the beginning or the end of the link copy, but we do want it to be there to tell a user that they are actively on the link itself.
- Thoughts on iOS proposed workaround (going to poorly wrapped form only when screen reader is on)
- My only issue with the override is a VoiceOver issue and not the way that you've done it. I'm not a fan of multiple swipes being needed to navigate through the entire text block, but that is also how VoiceOver seems to do things on the web also and any users who are familiar with the way that VoiceOver works would understand and be fine.
TimRoe
Description
Split from ticket #168 to tend to specific accessibility concerns around the Inline variant of the Link component.
As a Veteran, I want to see links within text that are formatted in a way that easy to read, so that I am not distracted by how the content is presented and can focus on the meaning of the content.
As part of this story we want to:
Look into the best way for our Link Component to support inline links in a way that is formatted well. See these Slack threads for more context:
Videos Pulled from Slack thread:
Videos 1 & 2 (iOS)
https://github.com/department-of-veterans-affairs/va-mobile-library/assets/8690976/caaaa2b3-f543-4029-bcdc-055c21a559d4
https://github.com/department-of-veterans-affairs/va-mobile-library/assets/8690976/2336c5af-e2f4-49cd-9507-a93d5aa29b58
Same 2 videos with proposed behavior when the screen reader is on:
Videos 3 & 4 (iOS)
https://github.com/department-of-veterans-affairs/va-mobile-library/assets/8690976/373f9cf9-7caf-4416-b89b-265cb21ad32e https://github.com/department-of-veterans-affairs/va-mobile-library/assets/8690976/459cee5b-3b3f-4bcf-a545-a1f868571ec2Android which behaves rather differently and may be mostly fine:
Android video
https://github.com/department-of-veterans-affairs/va-mobile-library/assets/8690976/8a832187-73b5-44d1-8eec-7d161dfeed84Acceptance Criteria
- [ ] Discuss options with Brea from an accessibility perspective, notably around: - How does a screen reader behave in web around hyperlinks within a paragraph - Is the Android behavior good? - Thoughts on iOS proposed workaround (going to poorly wrapped form only when screen reader is on) - [ ] General point: look into whether a11yLabel override for non-Link text is working as expected (not checked on #168) - [ ] General point: validate a11yHints work within inline Links (not checked on #168) - [ ] If general Android behavior is satisfactory: - [ ] Fix whatever around the icon area is making the screen reader read "0" aloud - [ ] Fix whatever is causing the a11yLabel to not be read on the first link in the Inline story - [ ] If not: implement preferred Android behavior - [ ] If proposed iOS workaround is satisfactory: - [ ] Proceed with [previous inline PR suggestion](https://github.com/department-of-veterans-affairs/va-mobile-library/pull/188#discussion_r1501114063) to clean this up by building the map first and only conditionalizing the `inlineSingle` setting to reduce duplcations - Test around with it--when initially split it was crashing so it was unable to be implemented, but [the problem was identified and fixed](https://github.com/department-of-veterans-affairs/va-mobile-library/pull/188/commits/a6944a8fb8d168338dea9fd81c481dd6b22b9f46) right before putting #168 to PR so the iOS workaround may be good as is - [ ] If not: implement preferred iOS behavior - [ ] Once both are working as desired, test in flagship app - Due to outstanding accessibility concerns, the Inline variant was not tested in app, but should be as it is significantly different than every other Link variety - Testing should include both accessibility pieces with this ticket as well as general non-screen reader behavior (e.g. wrapping generally and at different font sizes) - Specific spots to check: - [ ] See lines 373-390 in `src/screens/BenefitsScreen/ClaimsScreen/AppealDetailsScreen/AppealStatus/AppealCurrentStatus/AppealCurrentStatus.tsx` of the flagship code - [ ] See `getLinkifiedText` function in secure messaging; [Dylan said more about it in Slack](https://adhoc.slack.com/archives/C05DQPHUVNZ/p1707924255729829?thread_ts=1707923272.834929&cid=C05DQPHUVNZ) - [ ] Check if bug #203 manifests in iOS in app or if it's specific to Expo/Storybook **Accessibility Requirements** - [ ] See normal ACs--whole ticket about accessibility ## Notes & Open Questions - Dev Notes: - Based on behavior observed, the aria-label (and possibly a11yHint) properties do not appear to be working for the RN Text version while they do work for RN Pressable version