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