Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(166)

Side by Side Diff: chrome/common/extensions/docs/server2/templates/articles/a11y.html

Issue 10832042: Extensions Docs Server: Doc conversion script (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: everything but svn stuff Created 8 years, 4 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
OLDNEW
(Empty)
1 <h1>Accessibility (a11y)</h1>
2
3
4 <p>
5 When you design an extension,
6 try to make it as accessible as possible
7 to people with disabilities such as
8 visual impairment, hearing loss, and limited dexterity.
9 </p>
10
11 <p>
12 Everyone &mdash; not just people with special needs &mdash;
13 can benefit from the alternative access modes
14 that accessible extensions provide.
15 For example, keyboard shortcuts are important
16 for blind people and people with limited dexterity,
17 but they also help power users get things done
18 more quickly without using a mouse.
19 Captions and transcripts give deaf people access to audio content,
20 but they are also useful to language learners.
21 </p>
22
23 <p>
24 People can interact with your extension in a variety of ways.
25 They might use a standard monitor, keyboard, and mouse,
26 or they might use a screen magnifier and just a keyboard.
27 Another possibility is a <em>screen reader</em>,
28 an assistive application tool that interprets
29 what's displayed onscreen
30 for a blind or visually impaired user.
31 A screen reader might speak out loud or produce Braille output.
32 </p>
33
34 <p>
35 Although you can't predict what tools people will use,
36 by following a few simple guidelines
37 you can write an extension that is
38 more likely to be accessible to more people.
39 The guidelines on this page aren't going to
40 make your extension accessible for absolutely everyone,
41 but they're a good starting point.
42 </p>
43
44
45 <h2 id="controls">Use accessible UI controls</h2>
46
47 <p>
48 First, use UI controls that support accessibility.
49 The easiest way to get an accessible control is to use a
50 standard HTML control.
51 If you need to build a custom control,
52 keep in mind that it's much easier
53 to make the control accessible from the beginning
54 than to go back and add accessibility support later.
55 </p>
56
57 <h3 id="htmlcontrols">Standard controls</h3>
58
59 <p>
60 Try to use standard HTML UI controls whenever possible.
61 Standard HTML controls (shown in the following figure)
62 are keyboard accessible, scale easily,
63 and are generally understood by screen readers.
64 </p>
65
66 <img src="{{static}}/images/a11y/standard-html-controls.png"
67 width="550" height="350"
68 alt="Screenshots and code for button, checkbox, radio, text, select/option, and link">
69
70
71 <h3 id="aria">ARIA in custom controls</h3>
72
73 <p>
74 ARIA is a specification for making UI controls accessible to screen readers
75 by means of a standard set of DOM attributes.
76 These attributes provide clues to the screen reader
77 about the function and current state of controls on a web page.
78 ARIA is a
79 <a href=" http://www.w3.org/WAI/intro/aria">work in progress at the W3C</a>.
80 </p>
81
82 <p>
83 Adding ARIA support to custom controls in your extension
84 involves modifying DOM elements to add attributes
85 Google Chrome uses
86 to raise events during user interaction.
87 Screen readers respond to these events
88 and describe the function of the control.
89 The DOM attributes specified by ARIA are classified into
90 <em>roles</em>, <em>states</em>, and <em>properties</em>.
91 </p>
92
93 <p>
94 The ARIA attribute <em>role</em>
95 is an indication of the control type
96 and describes the way the control should behave.
97 It is expressed with the DOM attribute <code>role</code>,
98 with a value set to one of the pre-defined ARIA role strings.
99 Because ARIA roles are static,
100 the role attribute should not change its value.
101 </p>
102
103 <p>
104 The <a href="http://www.w3.org/WAI/PF/aria/roles">ARIA Role Specification</a>
105 holds detailed information on how to pick the correct role.
106 For example, if your extension includes a toolbar,
107 set the <code>role</code> attribute of the toolbar's DOM element as follows:
108 </p>
109
110 <pre>
111 &lt;div role="toolbar"&gt;
112 </pre>
113
114 <p>
115 ARIA attributes are also used to describe
116 the current state and properties of controls of a particular role.
117 A <em>state</em> is dynamic and should be updated during user interaction.
118 For example, a control with the role "checkbox"
119 could be in the states "checked" or "unchecked".
120 A <em>property</em> is not generally dynamic,
121 but is similar to a state
122 in that it expresses specific information about a control.
123 For more information on ARIA states and properties,
124 refer to the
125 <a href="http://www.w3.org/TR/wai-aria/states_and_properties">W3C States and Pro perties specification</a>.
126 </p>
127
128
129 <p class="note">
130 <b>Note:</b>
131 You don't have to use
132 all of the states and properties available for a particular role.
133 </p>
134
135 <p>
136 Here's an example of adding
137 the ARIA property <code>aria-activedescendant</code>
138 to the example toolbar control:
139 </p>
140
141 <pre>
142 &lt;div role="toolbar" tabindex="0" aria-activedescendant="button1"&gt;
143 </pre>
144
145 <p>
146 The
147 <a href="http://www.w3.org/WAI/PF/aria/states_and_properties#aria-activedescenda nt"><code>aria-activedescendant</code></a>
148 property specifies which child of the toolbar receives focus
149 when the toolbar receives focus.
150 In this example, the toolbar's first button
151 (which has the <code>id</code> "button1")
152 is the child that gets focus.
153 The code <code>tabindex="0"</code>
154 specifies that the toolbar
155 receives focus in document order.
156 </p>
157
158 <p>
159 Here's the complete specification for the example toolbar:
160 </p>
161
162 <pre>
163 &lt;div role="toolbar" tabindex="0" aria-activedescendant="button1"&gt;
164 &lt;img src="buttoncut.png" role="button" alt="cut" id="button1"&gt;
165 &lt;img src="buttoncopy.png" role="button" alt="copy" id="button2"&gt;
166 &lt;img src="buttonpaste.png" role="button" alt="paste" id="button3"&gt;
167 &lt;/div&gt;
168 </pre>
169
170 <p>
171 Once ARIA roles, states, and properties are added to the DOM of a control,
172 Google Chrome raises the appropriate events to the screen reader.
173 Because ARIA support is still a work in progress,
174 Google Chrome might not raise an event for every ARIA property,
175 and screen readers might not recognize all of the events being raised.
176 You can find more information on ARIA support in Google Chrome in the
177 <a href="http://www.chromium.org/developers/design-documents/accessibility#TOC-W AI-ARIA-Support">Chromium Accessibility Design Document</a>.
178 </p>
179
180 <p>
181 For a quick tutorial on adding ARIA controls to custom controls, see
182 <a href="http://www.w3.org/2010/Talks/www2010-dsr-diy-aria/">Dave Raggett's pres entation from WWW2010</a>.
183
184 <h3 id="focus">Focus in custom controls</h3>
185
186 <p>
187 Make sure that operation and navigation controls of your extension
188 can receive keyboard focus.
189 Operation controls might include
190 buttons, trees, and list boxes.
191 Navigation controls might include tabs and menu bars.
192 </p>
193
194 <p>
195 By default, the only elements in the HTML DOM
196 that can receive keyboard focus
197 are anchors, buttons, and form controls.
198 However, setting the HTML attribute <code>tabIndex</code> to <code>0</code>
199 places DOM elements in the default tab sequence,
200 enabling them to receive keyboard focus.
201 For example:
202 </p>
203
204 <pre>
205 <em>element</em>.tabIndex = 0
206 </pre>
207
208 <p>
209 Setting <code>tabIndex = -1</code> removes the element from the tab sequence
210 but still allows the element to receive keyboard focus programmatically.
211 Here's an example of setting keyboard focus:
212 </p>
213
214 <pre>
215 <em>element</em>.focus();
216 </pre>
217
218 <p>
219 Ensuring that your custom UI controls include keyboard support
220 is important not only for users who don't use the mouse
221 but also because screen readers use keyboard focus
222 to determine which control to describe.
223 </p>
224
225 <h2 id="keyboard"> Support keyboard access </h2>
226
227 <p>
228 People should be able to use your extension
229 even if they can't or don't want to use a mouse.
230 </p>
231
232 <h3 id="navigation"> Navigation </h3>
233
234 <p>
235 Check that the user can navigate between
236 the different parts of your extension
237 without using the mouse.
238 Also check that any popups on page actions or browser actions
239 are keyboard navigable.
240 </p>
241
242 <p id="builtin">
243 On Windows, you can use <b>Shift+Alt+T</b>
244 to switch the keyboard focus to the toolbar,
245 which lets you navigate to the icons of page actions and browser actions.
246 The help topic
247 <a href="http://www.google.com/support/chrome/bin/static.py?hl=en&page=guide.cs& guide=25799&from=25799&rd=1">Keyboard and mouse shortcuts</a>
248 lists all of Google Chrome's keyboard shortcuts;
249 details about toolbar navigation
250 are in the section <b>Google Chrome feature shortcuts</b>.
251 </p>
252
253 <p class="note">
254 <b>Note:</b>
255 The Windows version of Google Chrome 6 was the first
256 to support keyboard navigation to the toolbar.
257 Support is also planned for Linux.
258 On Mac OS X,
259 access to the toolbar is provided through VoiceOver,
260 Apple's screenreader.
261 </p>
262
263 <p>
264 Make sure that it's easy to see
265 which part of the interface has keyboard focus.
266 Usually a focus outline moves around the interface,
267 but if you’re using CSS heavily this outline might be suppressed
268 or the contrast might be reduced.
269 Two examples of focus outline follow.
270 </p>
271
272 <img src="{{static}}/images/a11y/focus-outline-2.png"
273 width="200" height="75"
274 alt="A focus outline on a Search button">
275 <br />
276 <img src="{{static}}/images/a11y/focus-outline.png"
277 width="400" height="40"
278 alt="A focus outline on one of a series of links">
279
280
281 <h3 id="shortcuts"> Shortcuts </h3>
282
283 <p>
284 Although the most common keyboard navigation strategy involves
285 using the Tab key to move focus through the extension interface,
286 that's not always the easiest or most efficient way
287 to use the interface.
288 You can make keyboard navigation easier
289 by providing explicit keyboard shortcuts.
290 </p>
291
292 <p>
293 To implement shortcuts,
294 connect keyboard event listeners to your controls.
295 A good reference is the DHTML Style Guide Working Group’s
296 <a href="http://dev.aol.com/dhtml_style_guide">guidelines for keyboard shortcuts </a>.
297 </p>
298
299 <p>
300 A good way to ensure discoverability of keyboard shortcuts
301 is to list them somewhere.
302 Your extension’s
303 <a href="options.html">Options page</a>
304 might be a good place to do this.
305 </p>
306
307 <p>
308 For the example toolbar,
309 a simple JavaScript keyboard handler could look like the following.
310 Note how the ARIA property <code>aria-activedescendant</code>
311 is updated in response to user input
312 to reflect the current active toolbar button.
313 </p>
314
315 <pre>
316 &lt;head&gt;
317 &lt;script&gt;
318 function optionKeyEvent(event) {
319 var tb = event.target;
320 var buttonid;
321
322 ENTER_KEYCODE = 13;
323 RIGHT_KEYCODE = 39;
324 LEFT_KEYCODE = 37;
325 // Partial sample code for processing arrow keys.
326 if (event.type == "keydown") {
327 // Implement circular keyboard navigation within the toolbar buttons
328 if (event.keyCode == ENTER_KEYCODE) {
329 ExecuteButtonAction(getCurrentButtonID());
330 <em>// getCurrentButtonID defined elsewhere </em>
331 } else if (event.keyCode == event.RIGHT_KEYCODE) {
332 // Change the active toolbar button to the one to the right (circular).
333 var buttonid = getNextButtonID();
334 <em>// getNextButtonID defined elsewhere </em>
335 tb.setAttribute("aria-activedescendant", buttonid);
336 } else if (event.keyCode == event.LEFT_KEYCODE) {
337 // Change the active toolbar button to the one to the left (circular).
338 var buttonid = getPrevButtonID();
339 <em>// getPrevButtonID defined elsewhere </em>
340 tb.setAttribute("aria-activedescendant", buttonid);
341 } else {
342 return true;
343 }
344 return false;
345 }
346 }
347 &lt;/script&gt;
348
349 &lt;div role="toolbar" tabindex="0" aria-activedescendant="button1" id="tb1"
350 onkeydown="return optionKeyEvent(event);"
351 onkeypress="return optionKeyEvent(event);"&gt;
352 &lt;img src="buttoncut" role="button" alt="cut" id="button1"&gt;
353 &lt;img src="buttoncopy" role="button" alt="copy" id="button1"&gt;
354 &lt;img src="buttonpaste" role="button" alt="paste" id="button1"&gt;
355 &lt;/div&gt;
356 </pre>
357
358
359 <h2 id="more"> Provide accessible content </h2>
360
361
362 <p>
363 The remaining guidelines might be familiar
364 because they reflect good practices for all web content,
365 not just extensions.
366 </p>
367
368 <h3 id="text">Text</h3>
369
370 <p>
371 Evaluate your use of text in your extension.
372 Many people might find it helpful
373 if you provide a way to increase the text size within your extension.
374 If you are using keyboard shortcuts,
375 make sure that they don't interfere with
376 the zoom shortcuts built into Google Chrome.
377 </p>
378
379 <p>
380 As an indicator of the flexibility of your UI,
381 apply the <a href="http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-c ontrast-scale">200% test</a>.
382 If you increase the text size or page zoom 200%,
383 is your extension still usable?
384 </p>
385
386 <p>
387 Also, avoid baking text into images:
388 users cannot modify the size of text displayed as an image,
389 and screenreaders cannot interpret images.
390 Consider using a web font instead,
391 such as one of the fonts collected in the
392 <a href="http://code.google.com/apis/webfonts/">Google Font API</a>.
393 Text styled in a web font is searchable,
394 scales to different sizes,
395 and is accessible to people using screen readers.
396 </p>
397
398 <h3 id="colors">Colors</h3>
399
400 <p>
401 Check that there is sufficient contrast between
402 background color and foreground/text color in your extension.
403 <a href="http://snook.ca/technical/colour_contrast/colour.html">This contrast ch ecking tool</a>
404 checks whether your background and foreground colors
405 provide appropriate contrast.
406 If you’re developing in a Windows environment,
407 you can also enable High Contrast Mode
408 to check the contrast of your extension.
409 When evaluating contrast,
410 verify that every part of your extension that relies on
411 color or graphics to convey information is clearly visible.
412 For specific images, you can use a tool such as the
413 <a href="http://www.vischeck.com/vischeck/">Vischeck simulation tool</a>
414 to see what an image looks like in various forms of color deficiency.
415 </p>
416
417 <p>
418 You might consider offering different color themes,
419 or giving the user the ability to customize the color scheme
420 for better contrast.
421 </p>
422
423 <h3 id="sound">Sound</h3>
424
425 <p>
426 If your extension relies upon sound or video to convey information,
427 ensure that captions or a transcript are available.
428 See the
429 <a href="http://www.dcmp.org/ciy/">Described and Captioned Media Program guideli nes</a>
430 for more information on captions.
431 </p>
432
433 <h3 id="images">Images</h3>
434
435 <p>
436 Provide informative alt text for your images.
437 For example:
438 </p>
439
440 <pre>
441 &lt;img src="img.jpg" alt="The logo for the extension"&gt;
442 </pre>
443
444 <p>
445 Use the alt text to state the purpose of the image
446 rather than as a literal description of the contents of an image.
447 Spacer images or purely decorative images
448 should have blank ("") alt text
449 or be removed from the HTML entirely and placed in the CSS.
450 </p>
451
452 <p>
453 If you must use text in an image,
454 include the image text in the alt text.
455 A good resource to refer to is the
456 <a href="http://www.webaim.org/techniques/alttext/">WebAIM article on appropriat e alt text</a>.
457
458 <h2 id="examples">Examples</h2>
459
460 <p>
461 For an example that implements keyboard navigation and ARIA properties, see
462 <a href="http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extension s/docs/examples/extensions/news_a11y/">examples/extensions/news_a11y</a>
463 (compare it to
464 <a href="http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extension s/docs/examples/extensions/news/">examples/extensions/news</a>).
465 For more examples and for help in viewing the source code,
466 see <a href="samples.html">Samples</a>.
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698