Accessibility and Links - Screen reader reads each line of link text as a separate link

Question

I have sent the site i'm working on to someone who checks whether its accessable or not, and the test came back with a reject regarding some links in the site.

There are 7 links, each of them in their own hoverable box, and in each box there is text, a headline and about 3-4 lines of more details. I'm happy with the design itself (visually) and want to stick with it.

Initially, the code looked like this:

<a href=# target="_blank" rel="noopener noreferrer">
    <strong> some headline </strong>
    <span> info1 <br/> info2 <br/> info3 </span>
</a>

the screen reader reads it like this: "link - some headline", and then "link - info1" and so on... even though its a single link!

After reading some about accessibility, I decided to not use the <br> element, since it causes problems in screen reading.

And so, I changed it to:

<a href=# target="_blank" rel="noopener noreferrer">
    <p><strong>some headline</strong>
       info1
       info2
       info3
    </p>
</a>

with css handling the break lines with the property "white-space: pre-line;" applied to <p> element.

Surprisingly, the screen reader still has the same problem. How can that be? there is only one <a> element.

I also tried switching places between <a> and <p> , to get a similar result and it also messed up the design.

Follow-up: Could it be that their reader is just not working well? I had that suspicion

Would love to get some insight on this, thank you.

Answer 1

When I started making my sites accessible, I downloaded a few addons (to simulate a reader) and a few readers. The result was that they had different rules.

Myth 4: All screen readers are exactly the same Not all screen readers are compatible (or as compatible) with every operating system, browser, and app, and user interfaces can differ considerably. Someone who's adept at Apple's VoiceOver may encounter a learning curve when switching to Android's TalkBack. Users will have their favorites, which is another reason that developers shouldn't test their content in a single computing environment.

From Bureau of Internet Accessibility

Mozilla guide talks about striking a balance.

ARIA Screen Reader Implementors Guide Live Regions This is just a guide. Live region markup is a complex area which is somewhat open to interpretation. The following is intended to provide implementation guidance that respects screen readers developers' need to try different things. The intention is to strike a balance between providing useful guidance on how to use the markup's intended meaning while supporting live regions as an area for screen readers to innovate and compete.

From Mozilla Guide on Aria