4

I have a menu with right arrows next to the elements that have child pages under them. The child items are not displayed in the menu, the arrow only indicates to the user that after they navigate to that page, they will be able to choose sub-sections.

I can also enter a text element that doesn't display visually but can be read by screen readers and other text-based browsers. What character or string of characters would be most widely useful for text-based browsing?

I have considered ">" because it can be understood by those who know that it appears visually similar to a right arrow, but I also have down arrows which would then be "v" and that seems potentially confusing. "→" doesn't work because it isn't being rendered during HTML rendering, it's just spelled out as text because it's added with CSS. Something like "item has sub-sections" seems long and inelegant. What would be most useful and widely compatible here?

7
  • What about : "more" "drill down" "enter" "follow" "expand" ?
    – Pierre
    Jul 10, 2014 at 17:20
  • 1
    Why not just add aria-haspopup="true" to your top-level items?
    – Brian
    Jul 11, 2014 at 20:59
  • Entities (like →) can’t be used in CSS. But why not the characters directly (like )?
    – unor
    Jul 11, 2014 at 23:43
  • They don't work properly in all browsers. In some, I was seeing a blank box instead of an arrow.
    – beth
    Jul 14, 2014 at 18:29
  • 1
    the answer provided below is very well documented. One tip I can give is to try and train yourself to think more auditory. One thing I like to do, when in doubt is use a browser development plugin that allows me to toggle css styles and images... if you disable all CSS and images, can you successfully navigate the site just by reading the text?
    – Grapho
    Jul 21, 2014 at 14:34

1 Answer 1

13
+100

You need to clearly communicate in a non visual sense the fact that the menu has sub menu items. When thinking about the problem like this it turns out that you aren't restricted to just output text as you can also use the text in the tags and attributes. For visually impaired users you should be thinking in text, not images (this is actually very good advice for writing alt attributes too btw).

Put the text in the html and hide with css

CSS is not parsed by screen readers, someone who is visually impaired has no real need for a visual skin on the site, they are more concerned with the readable text and the mark-up itself being friendly to the tools they use. You can then add into the element that displays the arrow that navigating here will display sub menu options.

Ignore the concept of the arrow

The arrow only really has purpose for visual users. It points in a certain direction and that implies certain things and is a standard based on visual consumption of other things. If you can't see it that meaning is somewhat lost so it would be better to step back and make mark-up decisions based on the information you want to communicate rather than trying to copy the graphic in text.

Use navigation friendly elements like lists and nav

You can see from this link how a screen reader groups semantically marked up HTML and allows the user to navigate around it. Things like nav tags and lists will be grouped as things the user can focus on that naturally imply a set of sub items so if the content is carefully marked up using these elements the process of understanding and navigating will become much easier in the absence of the arrow visual.

http://webaim.org/techniques/screenreader/

By knowing they are in a navigation structure the announcement that sub items are viewable by clicking will feel more natural.

Use ARIA roles

ARIA is a new standard of html element attribute mark-up which is designed specifically to support accessibility and semantics on the web. It allows you to mark any element as being navigation, search, content etc. that the screen reader or other assistive technology can interpret. It gives you further strong control over the HTML.

http://alistapart.com/article/aria-and-progressive-enhancement

You can also look at this list here to find the most appropriate aria role:

http://www.w3.org/TR/wai-aria/states_and_properties

Hiding things

This ties in with the first point ... make sure any methods used to hide things don't render them invisible to screen readers. For example, the css property display=none is inaccessible as the screen reader won't render it. So when you do put the accessible text into the html don't then hide the element with an inaccessible css declaration.

Chris Colyer touches on the subject here as well as detailing other ways to hide content, as usual, the information on this site is excellent:

http://css-tricks.com/places-its-tempting-to-use-display-none-but-dont/

Test

Once you have built a prototype there are two ways you can test it. Firstly, by using real people who will consume your content and getting them to give feedback on how accessible the content is. Secondly, install and fire up as many screen reading technologies as you can, put a blindfold on and use them to consume your content. This will help you see things from the perspective of a visually impaired user and will highlight any issues you might have.

Some useful tools are: http://www.standards-schmandards.com/projects/fangs/

By putting all this together you will be able to clearly communicate what each menu is and make it very easy for screen readers. Essentially you are still using text, just in different places, such as as tags or attributes, but in such a way that the visually impaired user knows what structure they are looking at.

In summary:

Use nav and list elements

Use aria roles

Use hidden text if needed, but hide it nicely!

Test

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.