2

I am looking to break up a word for display purposes, but would like to maintain accessibility if a screen reader were to access the word. Is this possible?

<span>T</span><span>itle</span>

<span>T</span><span>i</span><span>t</span><span>l</span><span>e</span>

I would like the two examples to read "Title" as that is essentially how they would display. The entities do not need to be spans and the block can be wrapped in another element if that is required.

What would be the best way of achieving this behaviour while allowing the letters to be styled individually, without the use of javascript?

Andrew
  • 1,179
  • 8
  • 15
  • 6
    Since `
    ` and `` are semantically neutral, I don't think this will affect screen readers at all. They should just read the word straight out. Worst case I can think of is they read each letter individually - why don't you just test?
     – junkfoodjunkie Nov 23 '16 at 12:06
  • 1
    @junkfoodjunkie *Worst case I can think of is they read each letter individually*. This is exactly the problem here. – Adam Nov 23 '16 at 20:18
  • Have you tried using other elements to wrap them? Like `` or similar? – junkfoodjunkie Nov 23 '16 at 20:23
  • Related: [Making an h2 tag with a strong tag inside accessible](http://stackoverflow.com/q/35444747/1591669) – unor Nov 24 '16 at 11:53
  • @Andrew, did you test this and using what screen reader(s)? If this is an issue with ChromeVox, you can probably not worry about it. I have yet to encounter a blind user who uses ChromeVox. A low vision user may use ChromeVox as a supplement, but is just as likely (IME) to use a proper screen reader, which does not exhibit the problem you outline (see my answer below). – aardrian Nov 25 '16 at 14:47
  • I do not have access to any hardware screen readers and I am aware that different versions can behave differently. I was looking to try and get custom fonts "working" inside outlook emails through a horrible image sprite hack. Was wanting to make sure that the hack did not destroy accessibility. Luckily I managed to get the requirements changed and so it is no longer a requirement. – Andrew Jan 09 '17 at 17:19

3 Answers3

0

You can also use the aria-label attribute on a wrapping span to ensure it is read the way you want it to be heard:

<span aria-label="Title"><span>T</span><span>itle</span></span>

This is also a useful technique for symbols and other content you want to ensure is read properly, but you should double-check on an actual reader to make sure it is actually spoken as intended.

ericwbailey
  • 9
  • 2
  • A `div` is neither landmark nor interactive content. An `aria-label` will not be read by a screen reader (and rightly so). – aardrian Nov 23 '16 at 20:53
  • @aardrian Why *"rightly"*. Isn't the `aria-label` an attribute applicable to any role element? (see: w3.org/TR/wai-aria-1.1/#aria-label) – Adam Nov 24 '16 at 09:39
  • I stand corrected. Thank you for the clarification, @aardrian! – ericwbailey Nov 24 '16 at 19:23
  • @Adam, neither `
    ` nor `` have any default roles. Regardless of that, SRs do not read an `aria-label` on those elements so it is moot anyway. Support trumps spec, for good or bad.
     – aardrian Nov 25 '16 at 14:43
  • @aardrian yes this has very bad support but they should support it as *"All elements of the base markup"* includes `div` or `span`. This would make our life easier ;-) – Adam Nov 25 '16 at 14:47
  • @Adam, I was not very clear. Per your own link, `aria-label` is applicable to any *role* element. Neither `
    ` nor `` have a role, neither is a role element. So it does not apply to them, nor should it. Both allow it per the HTML 5 spec (so it is valid if you add a valid `role` attribute), but no AT should support it unless it has a role. If it becomes `` then AT will support it because it is a valid application of `aria-label` (wrong, but valid).
     – aardrian Nov 25 '16 at 18:42
  • @aardrian AT may support the `aria-label` on text elements but there's no obligation they do. @Steve-Faulkner provides a great explanation here: http://stackoverflow.com/questions/32951169/aria-label-aria-labelledby-and-aria-describedby-very-unforeseeable-behaviour-i#answer-32971759 – Adam Nov 25 '16 at 19:53
  • @Adam Agreed. Poor choice of the word "will" in my statement, especially since nobody can really control what AT will choose to support. – aardrian Nov 26 '16 at 01:13
0

I made a demo of your example: http://s.codepen.io/aardrian/debug/wodLOz

Both NVDA and JAWS read each one as "title." What that tells me is that you are unlikely to have to do anything as they are read fine.

A div is neither landmark nor interactive content. An aria-label will not be read by a screen reader (and rightly so). So that approach would not not work anyway. If you were stuck, I would look at accessible off-screen options anyway.

Just fire up more screen readers and give it a go (VoiceOver, TalkBack, Orca, Narrator are good ones to use).

Community
  • 1
  • 1
aardrian
  • 8,581
  • 30
  • 40
0

The problem here seems to reside in your screenreader or the way you use it.

Using Chromevox, I can see this "bug" when I navigate directly (using shortcut CHROMEVOX+arrow) to the element, but not when I launch the whole page read (using shortcut CHROMEVOX+R).

The problem is due to the granularity used to read the document. Unfortunately the current version of Chromevox is so buggish that I can't find any solution to change that granularity using the defined shortcut (CHROMEVOX+-).

Note that as long as you use non-block-level elements, a good screen reader should announce this correctly, which is not the case of Chromevox, for instance which handles differently those elements:

<b>T</b>itle  <-- This is read separately (but should not)

and

<span>T</span>itle  <-- This is (correctly) read as a whole word

Chromevox is a very peculiar screen reader because it's the only one who does not use the native browser accessibility API. Others screen reader won't even know that the text is contained inside a span.

Adam
  • 17,838
  • 32
  • 54