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
aria-haspopup="true"
to your top-level items?→
) can’t be used in CSS. But why not the characters directly (like→
)?