Forum Discussion

SashaVodnik-857's avatar
SashaVodnik-857
Community Member
3 years ago

Screen reader issue with tab blocks

My team and I have been exploring our content with the Apple Voiceover screen reader to learn how screen reader users interact with it. Today we happened upon an odd issue: in a Tabs block, the text of one tab included our company name followed by other words (DOCUSIGN USE CASE MAP TOOL). The company name was read letter-by-letter, and the remaining words were treated as words. 

I did some research and learned that this can be a side-effect of using the CSS property text-transform: uppercase. I inspected the element in my browser and this is indeed how Rise formats the tab text. The proposed solution I found online is to add an aria attribute to the text to make it clear it's not an acronym, but obviously this is not something I can implement for my content within Rise. 

Is mitigating this issue on your accessibility roadmap? Or do you have other suggestions for making this content available to our users who use screen readers?

More info on the issue here: https://www.stefanjudis.com/today-i-learned/text-transforms-affects-screen-readers-too/

rise 360
  • MarvieYap-Mulde's avatar
    MarvieYap-Mulde
    Former Staff
    3 years ago

    Hi Sasha! Thanks for reaching out!

    I cannot reproduce the behaviour you described with the phrase "DOCUSIGN USE CASE MAP TOOL". Voice Over does announce "Docusign" as a word and not spelled out. I made screen recordings for you just in case I'm missing anything that you can point out.

    VO + Safari Test 
    JAWS + Chrome Test
    NVDA + Edge Test

    In the meantime, thank you for sharing your research regarding the CSS property "text-transform". I don't have much experience with CSS interfering with screen readers in particular, but your sample proves it may influence it. It does, however, seem to be an edge case for Voice Over having problems with some words, like "Add", in the context of using the CSS property text-transform in the example. This property intends to separate the visual presentation (displaying as uppercase) while maintaining its semantic meaning in the HTML, which works quite well across various screen readers. I made recordings if you are curious.

    VO reading html buttons (in this recording I'm showing the source)
    JAWS reading html buttons
    NVDA reading html buttons

    There could just be some off words with Voice Over, but I did not encounter a problem with the word "Docusign". Will be waiting for your reply!

    Cheers!

    Marvie

  • SashaVodnik-857's avatar
    SashaVodnik-857
    Community Member
    3 years ago

    Thanks for your detailed response and careful research, Marvie! 

    I did my testing using VoiceOver + Chrome, so perhaps that's the root of my issue. I understand that VO works best with Safari, so perhaps there are some compatibility issues between VO and Chrome that affect this. I'm relatively new to testing with screen readers, so it's useful to know that in a variety of situations this text is read as expected. I may need to rely on learners who use screen readers being familiar with issues like these and making their own choices around reader + browser combination to mitigate them.

    Many thanks.

Related Content