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