OLD | NEW |
(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 — not just people with special needs — |
| 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 <div role="toolbar"> |
| 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 <div role="toolbar" tabindex="0" aria-activedescendant="button1"> |
| 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 <div role="toolbar" tabindex="0" aria-activedescendant="button1"> |
| 164 <img src="buttoncut.png" role="button" alt="cut" id="button1"> |
| 165 <img src="buttoncopy.png" role="button" alt="copy" id="button2"> |
| 166 <img src="buttonpaste.png" role="button" alt="paste" id="button3"> |
| 167 </div> |
| 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 <head> |
| 317 <script> |
| 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 </script> |
| 348 |
| 349 <div role="toolbar" tabindex="0" aria-activedescendant="button1" id="tb1" |
| 350 onkeydown="return optionKeyEvent(event);" |
| 351 onkeypress="return optionKeyEvent(event);"> |
| 352 <img src="buttoncut" role="button" alt="cut" id="button1"> |
| 353 <img src="buttoncopy" role="button" alt="copy" id="button1"> |
| 354 <img src="buttonpaste" role="button" alt="paste" id="button1"> |
| 355 </div> |
| 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 <img src="img.jpg" alt="The logo for the extension"> |
| 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>. |
OLD | NEW |