twilio-labs/paste

Screenreader experience when using truncate is broken - two related issues

hjbrown11 opened this issue · 4 comments

Description

When I wrap text in truncate, I expect it to get read out by VoiceOver/ other screenreader app, however this does not happen.

Please see the following codesandbox example - to experiment with this, use VoiceOver on mac (system settings, accessibility, VoiceOver). Click in the right hand side of the codesandbox where the three headings are. Activate VoiceOver and click the right-hand side of the codesandbox, from here, press CTRL + OPT + H / CTRL + OPT + SHIFT + H to navigate up and down the headers. The expected behaviour is what happens in headers 1 and 3 where voiceover will read 'Heading level 3 Hi'.

This works:

        <Heading as="h3" variant="heading20">
          Hi
        </Heading>

Strangely, this also works (having truncate wrapped in an Anchor element):

        <Heading as="h3" variant="heading20">
          <Anchor href="#">
            <Truncate title="hi">Hi</Truncate>
          </Anchor>
        </Heading>

However, this does not:

        <Heading as="h3" variant="heading20">
          <Truncate title="hi">Hi</Truncate>
        </Heading>

https://codesandbox.io/s/paste-truncate-screenreader-truncate-forked-2fwhd1?file=/src/index.tsx


As well as this, we have issues whereby text gets read out three times when it's wrapped in the truncate component.

To test this, please activate VoiceOver again, and click on the right panel of the codesandbox below, then press CTRL + OPT + SHIFT + down arrow (to get to the text elements). From there, please navigate using CTRL + SHIFT + left arrow / right arrow. You will see that normal text gets read out once, but when you hit text with truncate, the text is read out three times. This leads to a poor user experience when multiple text elements have truncate as this will lead to a large amount of text read out repeatedly and a lot of clicking to try and navigate to the next items.

https://codesandbox.io/s/paste-truncate-screenreader-issue-multiple-text-readouts-forked-4kdvi5?file=/src/index.tsx

Link to Reproduction

https://codesandbox.io/s/paste-truncate-screenreader-truncate-forked-2fwhd1?file=/src/index.tsx:676-785

Steps to reproduce

Please see above.

Paste Core Version

19.1.0

Browser

Chrome

Operating System

  • macOS
  • Windows
  • Linux

Additional Information

No response

Hi There

As with all AT and Browser combinations not all are as perfect as we would like, and this looks to be one of those situations.

Voice Over is designed to work best with Safari, and as such this example case works perfectly. I've also tested both codesandboxes on Windows in Chrome, Edge and Firefox using NVDA and they all work as expected. Truncated works read, and not repeated.

We'll have a look at some other test cases to investigate further, but I'm not too concerned about it right now. It's just one of those things that sometimes a browser will have a minor regression and not correctly communicate the text node correctly to the accessibility tree.

Largely, you should be aware that VO and Safari, and Window + NVDA / Jaws are the most common uses of screenreaders and they still work as expected for me.

Thanks for taking an interest and testing though, keep em coming

Hey Simon, thanks for getting back!

We have suggestions of browsers to use with original Flex (primarily Chrome, with some Edge) which we say we fully support: https://www.twilio.com/docs/flex/developer/ui/requirements.

I'm trying to find a solution which works on Chrome to ensure that we're providing a good experience for these users. It's great to hear that some cases are working - are you aware of any workarounds for this VoiceOver/Chrome issue, or is this simply with the browser and VoiceOver? Ideally we wouldn't want to tell users which assistive technology they should use, it would just be great to know if there's anything we can do on our end to prevent this!

Hi @hjbrown11

I wouldn't personally do anything about it right now. I suspect the vast majority of your users will be Windows based and it works just fine.

I don't try to over correct for small browser issues that might remedy themselves in the next chrome version, because you might end up creating technical debt you forget about that makes the experience much worse for AT users.

As an example, throwing an aria-label on the heading element might force VO to announce it in the short term, but if you change the the heading text, you now need to change it twice. Or the AT user will get a different version of the text than is displayed.

Thanks so much Simon, I really appreciate your input because I'm on mac and can't download Jaws or NVDA, so it's great to know the scale of the issue isn't as large as previously thought 😊 I'm also new to software engineering, so any and all learning is super valuable