How do you get a screen reader to properly read something like:
<nav>
Home
FAQ
Contact
</nav>
(I.e. read it as "F A Q" instead of "faq").
It doesn't make sense to use <abbr> here since "FAQ" is well-known.
I've tried:
speak-as: spell-out; CSS property, but apparently it's not well supported by screen readers and seemingly has about 3.5% global browser support anyway
FAQ which works on my screen reader (Orca). However, I'm worried some will read out the bullet points, and I believe aria-label is meant for interactive elements so I'm not sure it's a good solution for things like <h1>FAQs</h1>. In fact I think many will ignore the label entirely for an h1
The <h1>FAQs</h1> issue raises further concerns about reading that out properly (i.e. the addition of the "s").
Is there a better solution to this?
IF you want to do something, the only really good answer is <abbr>.
As you have said, though, FAQ is a well known acronym, and as such, you don't need to expand it explicitly.
If you don't want to use <abbr>, or as in the present case, judge that it's unneeded because the abbreviation is so common, in fact, don't do anything else.
You may use aria-label on a link, or visually hidden / off screen text, but in fact it's bad ideas, because you are probably going to create more problems than to solve.
<abbr> is good because you can decide, in screen reader options, whether abbreviations have to be expanded or not.
For the rest, most screen readers come with a pronunciation dictionary, normally customizable by the user. If they don't understand the word "FAQ" pronounced as such, they can add it in their dictionary to make it pronounced as "Frequently asked questions" or "F, A, Q", depending on their own preferences.
If you interfere in there and force the pronunciation to something the user doesn't know, they will maybe not understand what it is; and hence you have made experience worse.
I am building a website and I am attempting to make it as accessible as I can by the use of ARIA tags, role tags etc.
A navigation menu item is "Changing Lives". Where this is being read out by screen readers as "Changing Lives" (as in "Gives" and not "Knives").
Another navigation menu item is "About Us" but it is being read out by screen readers as "About U.S.".
I'm looking for assistance in how to force pronounciations for screen readers.
Don't worry about it, there are many words that screen readers do this on.
The only way you can influence pronunciation (while adhering to best practices) is to set the HTML lang attribute (language) correctly.
With regards to your About Us issue, capitalisation plays a big part in pronunciation. If you have used upper case (either in CSS or in HTML) it may exhibit this behaviour.
Above all do not resort to hacks such as double letters to fix this.....fixing it in one screen reader will break it in 3 others....just follow best practices.
You have the same problem as the user in the following question, and the same answer should apply:
VoiceOver pronunciation issue: "Live" "ADD"
you can ignore it,
you can use different words.
Trying to make my app WCAG complaint. There are a few places where text is displayed on the screen but not meant to be read by users. One is when an offer is not eligible, we show the offer but lower the contrast to denote the offer can not be made. The other is we show case numbers at the bottom of the app. These are captured by users in screen shots when they report bugs, and used by support to track the issue, but not meant to be read by users.
Is there any way to denote that these fields are not meant to be read by the user and therefore do not need to meet WCAG contrast ratios?
Let me rephrase your question...
How to markup a purely decorative text in order to make it compliant with WCAG?
WCAG does not have the notion of purely decorative text, as it might be subject to abuse.
At less, you have to consider using aria-hidden in order for the text not to be read by screen readers.
The difficult part of that is : how might a visitor understand that a text is not intended to be read? Is the assumption that a non readable text, with poor contrast, is something you have to ignore is really helping readability? No.
That being said, if you just want to fool automated tools, you have many possibilities like playing with transparency, replacing HTML portion with img canvas after load, etc. But this won't help accessibility, nor readability.
You're trying to convey one information ("do not read that") using only color difference, which is clearly targeted by the G182 technique : Ensuring that additional visual cues are available when text color differences are used to convey information.
It is a better solution to find a matching color to preserve the minimum contrast ratio for a given color (easy way : try black or white).
How Screen reader behave with <hr> <b> <i> <big> <small> <br /> ?
I am a jaws user and tags such as
<b> <big>
etc are not read in any special way to distinguish them from the rest of the page by default. If you want to point out a specific region of a page follow the stackoverflow example and use headings. I can quickly go from question to question since they each have there own heading, and when viewing a question can quickly jump from the question to the answers. ANother good example of heading usage is the way that google reader gives each headline it's own heading.
Really depends on the screen reader. Typically they will ignore tags they're not expecting, read some tags and change the tone of text surrounded by others.
The best way to find out is to run it through the one you're intending to support. For example, JAWS (a widely used screenreader) has a 40 minute demo that you could use. Bear in mind that this will be different for other screenreaders.
The rule of thumb is to make sure your markup is as semantic as possible and also conforms to what users of screenreaders are expecting (trying to be clever or overly helpful can actually be counterproductive if it is different from every other site your visitors have been to).
Is there any reason to avoid using text-align: justify;?
Does it reduce readability or cause problems?
Firstly, this is purely a design-related problem and solution. The design of your grid specifies if justifying text is needed. I think justify align alone has no major effect on usability. Bad typography that makes text illegible is what decreases usability. That said, make sure you have solid contrasts and a good balance of spacing in your type. Font-size matters too.
This site is a successful attempt at justifying text online. Since you can't control the spaces between letters and words nearly as much with CSS as you can with InDesign, it's a lot harder to justify text and not have 'rivers' of whitespace run down your rows, which happens when the spaces between words exceeds the spaces between lines. Things that make justifying text difficult: long words, row widths that don't hold enough words, and too much contrast between the text and the background colors; they make the rivers appear wider and more apparent.
The typographic ideal is to have an even text-block, where if you squint the text block becomes a uniform solid shade. So if you keep text at about 10px and 60% gray on white background, and have rows that fit about 20 words, justify align shouldn't look ugly. But keep in mind this does nothing to improve usability. Small, relatively light text annoys a lot of people, especially the older readers.
I should note that with (soft hyphenation) correctly separating long troublesome words like superawesome you can mimic proper typesetting (e.g. InDesign). There's a lot of stuff out there to help you do this. I would recommend the logic for hiding, manipulating, and displaying the text to be done on the client side, perhaps with this.
Edit: As others mention below, css hyphens are possible now, except not feasible (not in Chrome). Plus, css4 offers even more control.
text-align: justify shouldn't be used in browsers at the moment. They aren't good at handling the minute details within and the output ends up containing lots of rivers and there's no support for hyphenation (other than soft hyphens).
Note above was written 4.5 years ago. Things are slowly changing... http://caniuse.com/#feat=css-hyphens
Edit:
Hyphenator was brought to my attention in this answer's comments. It looks like it makes text-align justify worth using, check out the sites that use it. You may want to use javascript to apply text-align justify before using this script so that those without javascript don't get caught out.
Edit 2:
CSS now allows for hyphenation with the hyphens property [browser support]. PPK is now saying to add it to your stylesheets, whilst Eric Meyer says just add it for mobile.
Edit 3:
A good little overview of things available to us now, with some SASS.
The problems brought up by others about justify alignment are more prevalent with narrow columns. If your columns are wide enough in relation to the size of your fonts and other parameters then it's ok to justify the text. Let's say you'd want a minimum of 12 to 15 words per line in average. More is better.
There's no technical reason not to - it's purely a design decision. Many people find that justified text is harder to read, but I guess it depends on your situation. Though it works fine for print, generally web browsers do not give enough control over the eventual output of text to guarantee that what you're serving won't look like crap on some people's screens.
Your best option is to avoid justification.
I cant think of a compelling reason why not to justify text - at a certain point the volume and width of content almost demand that it be justified. Of course, you'll get issues with content consisting of certain word combinations, but to my mind if you're seeing rivers and unusually large spaces between words you have a different problem altogether - one of readability and clarity.
What I would avoid, at all costs, is centered body text. I don't think there's a greater red flag of ammateurish web design than that.
I prefer left justification (text-align: left) because it's generally more readable. It's also quicker to read evenly-spaced words, so I hear. Unless you have a stylistic reason for using justify, keep it left, right, or center. Especially for body text, use left. (Actually, you'd want something like "forward" for text in the other direction (e.g. Hebrew)...)
Justification should not be used without hyphenation. Here is a PHP based hyphenation library, and a port of this library to a WordPress plugin: wp-Typography.
Like any web design question... it depends. As has been suggested, justified text does not usually end up looking good in narrow columns. I'd recommend against it as a general rule in sidebars as sidebars are usually narrow.
With body copy at the often recommended 10 words per line (or with any amount above that) you will probably be able to get away with justified text and have it look reasonably good most of the time unless you're using a lot of really long words and/or strings.
I think I've pimped this site on StackOverflow before, but Jon Tan uses justified text in his body copy (within articles) and it looks great 99.99% of the time.
Erhh... No...!
[seriously] WordPress uses justify, and I think that's a pretty strong statement in regards to whether or not it decreases readability...
You can also use text-justify:newspaper. The text-justify css tag helps you control how you wrap the text when you justify
Text justification can be done in several ways.
Couple of definitions: Adjusting the spacing between words is "tracking" Adjusting the spacing between characters is "kerning" Good layout programs do some kerning automatically, and it varies by letter pair. The va of variable can be kerned closer than the xa in exact. Good fonts have built in tables of kerning hints to aid in this process.
In early days of monospace fonts it was done by inserting extra spaces between words. This made for very clunky looking output. If you had 4 spaces at the end of the line, and 6 spaces in the line, 4 of them would become double spaces.
Monospace fonts shouldn't be justified.
With variable width fonts, we have em spaces, en spaces, etc, and so the space could be better distributed.
I think this is where most browsers are now. It works reasonably well most of the time. For it to work well the following conditions need to hold:
You need a reasonable number of words on a line.
A large word at the end of the line can make problems.
The average word in English is 5 characters. So on the average you will have 5 characters (the 5 character word plus space wouldn't fit so gets bumped to the next line)
If you have 10 words on the line, then you need to add about half a standard space to each interword gap.
If the last word is a long one, like "headaches" and there isn't room for it, now you have 10 spaces to distribute. This starts to look bad.
This is where a hyphenation dictionary comes into play. Hyphenation can be done by algorithm, but there are enough exceptions that having a dictionary helps a lot. (There is a special character for soft hyphens for words not in your dictionary.)
Hyphenation can split a word so that the the line fills more evenly.
Empirically I decided that a 65 em line length made a good compromise. This gives 11-13 words per line a lot of the time.
Another approach to justification is to split the space up between characters. This avoids some of the problems above, but still looks odd if you are distributing a lot of space in not enough line. You see this in newspapers now and then where a word seems to have a full space between each character. This is a good argument for a longer line.
Good typesetting programs (InDesign, *TeX, Framemaker) do a combination of extra space in interword gaps, and tiny extra spaces between characters.
There is a new kid on the block, text-justify that can be used in CSS to modify the use of text-align: justify. Nominally it accepts the options
auto (default)
interword
inter-character (+ distribute for legacy reasons)
none
CanIuse https://caniuse.com/#search=text-justify
CSS working group https://drafts.csswg.org/css-text-3/#text-justify-property
CanIuse reports compliance only for Firefox right now, Chrome supports it but requires that you enable experimental features. CanIuse claims that support is buggy. Going to the Chromium bug tracking site, claims that it's fixed. Go figure. Haven't tested.
Other pragmatic points:
I made four changes to my site's style sheet:
Maximum line length of 65 rem
body font increase to 110%
leading increase to 125%
Justified text.
The result was that time on site and pages per session doubled.
Anecdotal, but may be worth your own test.
I think it is perfectly OK on print, but it is clunky on most Web browsers, by lack of fine control of spacing and hyphenation. Typographers can even play slightly on letter spacing or font contraction in some cases, as pages/columns (at least in magazines) can be finely tuned.
It should be mentioned that Internet Explorer (at least) up to version 8 does not render text-align: justify correctly. Instead it is interpreted as text-align: center.
Here is more info: text-align: justify
Caused me some headaches to find out why IE kept centering stuff. Maybe it saves somebody else some time.