This document discusses various topics relating to accessibility and compatibility of websites for people using assistive technologies. It provides tips on how to make forms, images, links, and other elements accessible. Key recommendations include using ARIA attributes to make interfaces accessible, providing text alternatives for non-text content, ensuring full keyboard and screen reader support, and avoiding any changes that could disrupt a screen reader user's experience of a page. The overall focus is on compatibility beyond just technical standards compliance.
27. “I don’t want to miss out on any content”
vs.
“I’m listening to the page at 300 words per minute
in a robotic computer voice - I don’t care about
the mood and feel of the page.”
focus on succinct content and functionality 27/49
28. images that are the only thing within
a link MUST have alt text
image buttons and hot spots too 28/49
29. avoid redundant text and
functionality
<a href=”http://apple.com/iphone”>
<img src=”iphone.jpg” alt=””><br>
Apple iPhone</a>
alternative text doesn’t have to be in the alt attribute 29/49
30. form labels
<label for=”firstname”>First Name:</label>
<input type=”text” id=”firstname”
name=”firstname” />
First Name:
text boxes, text areas, select menus,
checkboxes, and radio buttons.
30/49
31. form labels
<label> is limited to one form control
use aria-labelledby for
multiple labels per control
or
multiple controls per label
31/49
32. form labels
Search
If a visible text label is not available, ensure the
form control is visually intuitive without it.
If so, provide the description in the title attribute
<input title=”search terms”>
... or an off-screen label 32/49
33. eldsets and legends
Shipping method
Overnight
Two day
Ground
Use for all groups of radio buttons and checkboxes
when a higher level legend is needed... and that’s all.
33/49
34. use buttons to submit forms,
not links
and ensure that buttons and links initiate a context
change (use focus() if necessary)
34/49
35. avoid accesskey and tabindex
...unless you're sure you know what you're doing.
learn the power of tabindex=”0” and
tabindex=”-1” 35/49
36. visually hiding content
• display:none and
visibility:hidden hide from
everyone... and that’s a good thing.
• position off-screen le with CSS for
screen readers
• use judiciously
36/49
38. hover is dead
the title attribute and onmouseover is (mostly)
incompatible with touch-screen devices, keyboard,
voice control, and screen readers
38/49
39. title attribute
• advisory information only
• ignored by screen readers, except...
• form elements missing labels
• <frame title=”navigation”>
• <acronym>/<abbr> ...usually.
39/49
40. “skip to main content” links?
Yes! Until browsers provide better keyboard
navigation for sighted users
40/49
41. “skip to main content” links?
you can position them off-screen if you must,
but make them clearly visible on :focus
one “skip” link is typically sufficient 41/49
44. enhance focus indicators
a:focus, a:hover {
outline:1px;
background-color:#ff0;
text-decoration:underline;
}
non-underlined links should become underlined on hover and focus
44/49
45. avoid screen reader “freakout” mode
when an element that has focus or is being read is
modi ed or destroyed 45/49
46. avoid screen reader “freakout” mode
use javascript focus() to manage focus,
if necessary
46/49
47. odds and ends
• Provide accurate, descriptive, succinct page titles.
• Don’t stress over screen reader pronunciation and
quirks.
• Ensure full keyboard accessibility.
• Support zoom/text sizes to (at least) 2X.
• Layout tables don’t (typically) affect accessibility. Don’t
use <th>, <caption>, or summary on layout
tables.
47/49
