1 NIST Special Publication 500-317 (DRAFT)

2

3

4 Cloud Computing and Accessibility 

5 Considerations

6

7

8

9 Robert B. Bohn

10 James Tobias

11

12

13 This publication is available free of charge

14

15

16

17

18

19

20

21

22

23

24

25

26
27

28

29 NIST Special Publication 500-317 (DRAFT)

30

31 Cloud Computing and Accessibility 

32 Considerations

33

34 Robert B. Bohn

35 Advanced Networking Technologies Division

36 Information Technology Laboratory

37

38 James Tobias

39 Inclusive Technologies

40 Princeton, NJ

41

42 This publication is available free of charge

43

44

45 March 2016

46

47

48

49

50

51

52

53

54

55

56 U.S. Department of Commerce 

57 Penny Pritzker, Secretary

58

59 National Institute of Standards and Technology 

60 Willie May, Under Secretary of Commerce for Standards and Technology and Director 

61

62
ii

63 This page is left intentionally blank.
iii

64 Reports on Computer Systems Technology

65

66 The Information Technology Laboratory (ITL) at the National Institute of Standards and 

67 Technology (NIST) promotes the U.S. economy and public welfare by providing technical 

68 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 

69 methods, reference data, proof of concept implementations, and technical analyses to advance 

70 the development and productive use of information technology. ITL’s responsibilities include the 

71 development of management, administrative, technical, and physical standards and guidelines 

72 for the cost-effective security and privacy of other than national security-related information in 

73 Federal information systems. This Special Publication 500-series reports on ITL’s research, 

74 guidance, and outreach efforts in Information Technology and its collaborative activities with 

75 industry, government, and academic organizations.

76

77 National Institute of Standards and Technology Special Publication 500-317

78 Natl. Inst. Stand. Technol. Spec. Publ. 500-317, 49 pages (March 2016)

79 CODEN: NSPUE2

80

DISCLAIMER 

This document has been prepared by the National Institute of Standards and Technology 

(NIST) and describes technical research in support of the NIST Cloud Computing Program.

Certain commercial entities, equipment, or material may be identified in this document in 

order to describe a concept adequately. Such identification is not intended to imply 

recommendation or endorsement by the National Institute of Standards and Technology, nor 

is it intended to imply that these entities, materials, or equipment are necessarily the best 

available for the purpose.

81

82 This publication is available free of charge.

83
iv

84 Acknowledgements

85

86 This document emerged from a series of discussions with a number of stakeholders through 

87 participation in the NIST Cloud Computing Accessibility Public Working Group, chaired by Robert

88 B. Bohn of the U.S. Department of Commerce, National Institute of Standards and Technology. 

89 The document contains input from members of the NIST Cloud Computing Accessibility Public 

90 Working Group who provided commendable contribution and guidance.

91

92 Contributors to this document are -

93

94 Steve Jacobs, The Ideal Group

95 Clayton Lewis, University of Colorado

96 Alex Li, Microsoft

97 Kathleen McCoy, University of Delaware

98 Jamal Mazrui, Federal Communications Commission

99 Alice A. Smith, Department of Homeland Security

100 Gregg Vanderheiden, U Wisconsin-Madison

101 Jay Wyant, State of Minnesota CIO
v

102 Table of Contents

103 Acknowledgements.........................................................................................................................iv

104 List of Figures:..................................................................................................................................vi

105 List of Tables:..................................................................................................................................vii

106 1. Introduction and Background.................................................................................................. 1

107 2. User Experiences of Inaccessibility.......................................................................................... 2

108 2.1. Introduction to Use Cases ............................................................................................... 2

109 3. From Use Cases to Barrier Categories..................................................................................... 5

110 3.1. Version control ................................................................................................................ 5

111 3.2. Reliance on browser........................................................................................................ 5

112 3.3. Platform quandary........................................................................................................... 5

113 3.4. Use of thin clients............................................................................................................ 6

114 3.5. Rich data visualizations ................................................................................................... 6

115 4. Applications Categories and Accessibility Guidance ............................................................... 6

116 5. New Cloud-Based Accessibility Opportunities ........................................................................ 8

117 5.1. Global Public Inclusive Infrastructure (GPII).................................................................... 8

118 5.2. Accessibility Application Programming Interfaces (AAPIs) ............................................. 9

119 6. The Role of Information Resources....................................................................................... 11

120 6.1. Example: the FCC's Accessibility Clearinghouse............................................................ 12

121 7. Cloud Computing Accessibility Taxonomy............................................................................. 13

122 7.1. Audiences and Goals ..................................................................................................... 13

123 7.2. The Dimensions............................................................................................................. 14

124 7.3. Draft Taxonomy............................................................................................................. 15

125 7.4. Taxonomy Mind Map .................................................................................................... 16

126 8. Conclusions............................................................................................................................ 19

127 Appendix A: Comments from Raising the Floor – International on "US Government Cloud 

128 Computing Technology Roadmap, Release 1.0 (Draft)"................................................................ 20

129 A1. Introduction................................................................................................................... 20

130 A2. General Accessibility Comments................................................................................... 20

131 A3. Global Public Inclusive Infrastructure............................................................................ 23

132 A4. Other Recommendations.............................................................................................. 24

133 Appendix B: Guidance for Cloud Computing Accessibility ............................................................ 25
vi

134 B1. General Guidelines........................................................................................................ 25

135 B2. Enterprise collaboration Tools - email, calendaring, IM ............................................... 26

136 B3. Customer relationship management (CRM) ................................................................. 27

137 B4. Web server / Content Management ............................................................................. 28

138 B5. Identity Management.................................................................................................... 28

139 B6. Document Retrieval / Library Systems.......................................................................... 28

140 Appendix C: The Role of Standards............................................................................................... 30

141 Appendix D: Current Taxonomies ................................................................................................. 33

142 D1. AbleData ........................................................................................................................ 33

143 D2. Access for All.................................................................................................................. 34

144 D3. Cloud4All Semantic Framework for Content and Solutions (SEMA)............................. 36

145 D4. EASTIN ........................................................................................................................... 38

146 D5. Global Accessibility Resource Initiative (GARI).............................................................. 39

147 D6. IndieUI User Context ..................................................................................................... 41

148 D7. ISO 9999:2011 ............................................................................................................... 42

149 D8. Job Accommodation Network (JAN) ............................................................................. 42

150 D9. M376 ............................................................................................................................. 44

151 D10. Raising the Floor............................................................................................................ 45

152 D11. Section 508.................................................................................................................... 46

153 D12. Tables of Taxonomies.................................................................................................... 47

154 D12.1. By Audience............................................................................................................... 47

155 D12.2. By Dimension............................................................................................................. 47

156 D13. Taxonomies found within technical standards; not included at this time.................... 48

157 D13.1. ICF .............................................................................................................................. 48

158

159 List of Figures:

160

161 Figure 1 - Cloud Accessibility MindMap ........................................................................................ 18

162 Figure 2 - Screenshot of AfA Voice Recognition attribute within the Control class...................... 34

163 Figure 3 - Screenshot of AfA Voice Recognition data model, showing “voice profile identity” as 

164 one of several attributes. .............................................................................................................. 35

165 Figure 4 - Screenshot of AfA showing details of “voice profile identity”. ..................................... 35
vii

166 Figure 5 - Screenshot of SAT navigation panes. ............................................................................ 37

167 Figure 6 - Screenshot of SAT content pane. .................................................................................. 38

168 Figure 7 - Screenshot of EASTIN search results at the Cluster level, indicating the number of hits.

169 ....................................................................................................................................................... 39

170 Figure 8 - EASTIN screenshot showing some of the results for “Assistive Products for 

171 Communication and Information ... Input devices for computers ... Input software”.................. 39

172 Figure 9 - Screenshot of GARI search portal front page................................................................ 40

173 Figure 10 - Screenshot of GARI search option page...................................................................... 41

174 Figure 11 - Screenshot of GARI list of accessibility features associated with cognitive disabilities, 

175 with definitions.............................................................................................................................. 41

176 Figure 12 - JAN’s main pathway: Information By Product or Service............................................ 43

177 Figure 13 - Product listing for Vision Impairments........................................................................ 44

178 Figure 14 - Screenshot of RtF taxonomy, showing both the Feature and Product hierarchies and 

179 first sub-categories........................................................................................................................ 46

180 Figure 15 - Screenshot of RtF taxonomy showing bottom-level feature details........................... 46

181 Figure 16 - Screenshot of ICF Browser showing Chapter structure within “Activities and 

182 Participation”................................................................................................................................. 49

183 Figure 17 - Screenshot of ICF Browser showing functional detail................................................. 49

184

185 List of Tables:

186 Table 1: Comments on NIST SP 500-293 Volume I with respect to Accessibility.......................... 21

187 Table 2: Comments on NIST SP 500-293 Volume II with respect to Accessibility......................... 22

188 Table 3: Comments on NIST SP 500-293 Volume I with respect to GPII....................................... 23

189 Table 4: Excerpt from NIST SP 500-291......................................................................................... 32

190 Table 5: Table B.2 shows the relationship between functional performance statements and 

191 specific requirements, indicating where the relationship is primary or secondary ..................... 45

192

193
NIST SP 500-317 Cloud Computing Accessibility Considerations 

1

194 1. Introduction and Background

195

196 The NIST Cloud Computing Program (NCCP) released a draft two-volume US Government (USG) 

Cloud Computing Standards and Technology Roadmap1 197 in November 2011 for public comments; 

198 it was published in final form in October 2014. The USG Cloud Computing Technology Roadmap 

199 lists ten requirements and several Priority Action Plans that should be followed to fulfill the 

200 requirements. Requirement #7 is to “Define unique government regulatory requirements and 

201 solutions.”

202

Section 508 of the Rehabilitation Act2 203 , among other laws, requires that federal employees and 

204 citizens have equal access to information and communication technologies (ICT) regardless of 

205 their disabilities. This qualifies as a “unique government regulatory requirement”, and 

206 accessibility is considered to be fundamental to this solution.

207

208 Some comments to the Roadmap focused on accessibility with regard to the above requirement 

209 (see Appendix A). Although the Program’s original goal was to stress three major challenge areas 

210 for USG adoption cloud computing in security, portability, and interoperability, it was evident 

211 that accessibility is as valid a challenge for the USG. Cloud computing solutions that address and 

212 highlight accessibility offer a path forward for an agency to fulfill its mission and requirements 

213 by providing a larger number of potential solutions that USG ICT managers can use to be 

214 creative in the development of new services and solve their unique accessibility requirements. 

215 As work progresses in cloud computing, it is important to promote, incorporate and discuss 

216 applicable standards in accessibility for cloud computing services as a discipline for investigation.

217

218 In response to the interest in cloud and accessibility, the NCCP formed a new Public Working 

219 Group (PWG) on “Cloud Computing and Accessibility” (CCA-PWG) in June 2013. This PWG will 

220 address the topics facing cloud computing with respect to accessibility, standards and usage. 

221 This document details the activity of that PWG, and is in part the key deliverable to date of the 

222 PWG. We hope that this document will be useful to its primary audience, ICT managers in 

223 federal agencies who are seeking to build accessibility into their cloud computing procurement 

224 and use.

 

1 US Government Cloud Computing Technology Roadmap Volume I: High-Priority Requirements to Further 

USG Agency Cloud Computing Adoption; and Volume II: Useful Information for Cloud Adopters, NIST SP 

500-293, http://dx.doi.org/10.6028/NIST.SP.500-293

2 http://section508.gov/
NIST SP 500-317 Cloud Computing Accessibility Considerations 

2

225 2. User Experiences of Inaccessibility

226 2.1. Introduction to Use Cases

227 Accessibility, and thus inaccessibility, are almost entirely concerned with user experiences. 

228 Background processes are relevant only to the extent that they affect how users receive, 

229 perceive, and act upon the information and communication that is before them.

230

231 To fully explore the issues of accessibility to electronic information, we have developed a series 

232 of use cases that explore how a user interacts in different circumstances or cases. This is 

233 especially useful in considering accessibility in cloud computing, due to the strong interaction 

234 effects among device, browser, assistive technology (AT), app, etc. In many cases it is clear that 

235 there are policy and process barriers as well as purely technological ones.

236

237 The following personas do not always reflect specific personal experience, but were collected or 

238 drafted to express known difficulties encountered by ICT users with disabilities, including federal 

239 employees, some of whom contributed to this document.

240

241 Cora is a customer service in a specialized work group that covers income from foreign sources. 

242 She is blind from birth and uses a Braille display connected to her computer. Most of the 

243 information she handles shows up in specific blocks on the screen, and she has learned the 

244 keyboard commands to give those blocks focus on the Braille display as needed. Unexpected 

245 software updates to the internal cloud application sometimes change the layout and cause the 

246 Braille display to lose focus. This requires some assistance from the IT support center to get her 

247 back on track; in the meantime her productivity is compromised. The IT support people have 

248 come to expect her calls whenever there is a software update. They serve other blind users, who 

249 use a range of screen readers and Braille output devices. Cora and her blind peers have tried to 

250 escalate this problem but have had limited success.

251

252 Garrett is a wounded veteran with a moderate cognitive disability as a maintenance technician 

253 in a remote area. He drives between work sites and uses a mobile device that lets him navigate 

254 by GPS and retrieve his work orders through the company’s app. Some work orders are 

255 confusing and he needs help. He must place a call to his supervisor, and slowly read aloud the 

256 text of the order. The supervisor then explains the work order and occasionally must text him a 

257 complete, simplified order, in a regular text messaging app. Keeping track of the company’s app 

258 and the separate text messages can be confusing as well, and makes Garrett’s recordkeeping 

259 less accurate, but it does let him get his maintenance work done. He and his supervisor talk 

260 about creating a simpler solution, but they do not have any resources to develop software or 

261 even explore what their organization may already have that they could use.

262

263 Deena is a program administrator at a federal contractor working on many projects with several 

264 agencies. She is an older worker and has been experiencing problems with her vision and 

265 memory. Her company and the multiple agencies she works with all use different management 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

3

266 applications, some in the cloud and some not. She has trouble keeping track of her logins and 

267 passwords; she keeps a ‘cheat sheet’ in her desk drawer, which is against policy. She also has 

268 trouble copying and pasting information from an agency application into her company’s 

269 management tool – the highlight color is yellow on a white background, which doesn’t work for 

270 her. So she copies the whole page, pastes it into a word processor with higher contrast, selects 

271 the text she wants to copy, and then pastes it into her company’s tool. At the end of the day, 

272 she has many open word processor pages that need to be saved or discarded, and this is very 

273 time consuming. She says “in the old days” most of her work was done by phone, informally 

274 checking in with her colleagues in the federal agencies she was working with, but that nowadays 

275 there is a need to document everything, which means more typing and reading than she can 

276 easily do. She gets tired and has headaches many times during the week. She attended a 

277 workshop for low vision solutions such as larger or clearer monitors and high contrast settings a 

278 few years ago, but did not follow up with her supervisor.

279

280 Roberto works as a statistical analyst. He is deaf and uses video relay and video remote 

281 interpreting to communicate with his workmates. His supervisor encourages him to use direct 

282 text instead whenever possible, for budget reasons. Roberto finds sign language to be a more 

283 effective form of communication. Some of the training videos he needs to use have poor quality 

284 captions with errors, and the transcripts do not let him know what is being said at what part of 

285 the video. He and his deaf peers informally exchange information about good and bad 

286 captioning training videos; some admit that they choose what training they take based on the 

287 quality of the captions. A recent problem has been an increase in the use of telecollaboration for 

288 project meetings. Sign language is not available at all on these meeting calls. Real-time 

289 captioning (CART) is not always available and the quality is mixed. When it is slow or incorrect, 

290 he misses opportunities to ask questions or make comments. Moreover, when he is reading 

291 captions he occasionally misses some content of the graphs in the main part of the screen, and 

292 has to review the recording of the session to catch up. Lately, he has been using his tablet to 

293 attend these sessions. This is good for his flexible schedule, but he has to balance the size of the 

294 captioning and chat panes with the size of the text in the main content pane. Depending on the 

295 content, this can be problematic. 

296

297 Virginia uses multiple applications plus email on a daily basis. Because of a spinal cord injury, 

298 she cannot use her hands for typing and has limited use of the mouse. She relies on Dragon 

299 Naturally Speaking, a speech recognition system that lets her speak words to type and say 

300 commands to control the computer. Virginia’s component is working with a cloud service 

301 provider who plans to provide software as a service and to utilize a virtual desktop as a delivery 

302 mechanism. Because the virtual desktop, Citrix Receiver, does not work with Dragon Naturally 

303 Speaking, Virginia will not be able to work unless an exception is made to continue supporting 

304 her current configuration. Virginia knows this because she works in the accessibility group.

305

306 Allen uses multiple applications plus email on a daily basis. Allen has been blind from birth. He 

307 cannot use a mouse because he cannot see the screen to follow the cursor. He uses a screen 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

4

308 reader, assistive technology that speaks the screen information to him and lets him control the 

309 computer with the keyboard. Allen is in Virginia’s component. His group is going to the virtual 

310 desktop next week. Allen doesn’t know that his assistive technology will not work with the 

311 virtual desktop and is facing a work stoppage next week. His situation and user needs in general 

312 were not considered during the planning process. The virtual desktop vendors claim that 

313 assistive technology will work if installed on the remote desktop. Allen’s agency has tested this 

314 and found that it works poorly or not at all. However, there is no requirement in place for the 

315 vendor to fix this compatibility problem in time for the transition; there is no timetable at all 

316 built into the service contract. The current plan is to have Allen use a separate system until the 

317 problem is resolved, but there is no clarity on how that will work or how long it will last. 

318

319 In order to make compliance training more interesting and ‘game-like’ Jason’s agency has begun 

320 to teach courses online so that units can track progress and compete for high scores and early 

321 completion of training. These courses often use graphics and interface elements that make it 

322 impossible for Jason, who is blind, to use a screen reader to independently complete the 

323 required training. The software developers did not follow best practices regarding accessibility, 

324 as it was not part of the contract. Jason often has difficulty completing courses, due to no fault 

325 of his own. One typical problem is that as the training application calculates his work to show 

326 progress graphically, his computer freezes and no record is retained. Jason’s supervisor has to 

327 request system logs of Jason’s training instead, which is time-consuming and cumbersome.

328

329 Nancy is an agency financial analyst with Attention Deficit Disorder. Her agency regularly 

330 requires her to teach using webinars. While the hosting software has the capacity to 

331 demonstrate calculations and can show the impact of proposed changes on the agency’s 

332 finances in near real time, the screen cannot be modified by individuals. Nancy is often 

333 distracted by incoming questions when teaching and loses her train of thought. As a work 

334 around, Nancy tried to call into the seminar and ask a colleague to change screens for her and 

335 field questions but this has led to confusion when the slides were not in sync or when students 

336 were asking for demonstrations of calculations needed in their jobs and Nancy needed to 

337 comment on specific results.

338

339 The agency Tuan works at has approved apps on mobile devices to gather and support cloud340 based data collection and analysis. Tuan, who has limited use of his hands, is knowledgeable 

341 about the assistive technology he needs, a switch selection system on his tablet. However, the 

342 apps his agency uses were not designed according to the accessibility recommendations for the 

343 operating system, which often change. Since the last update, Tuan is unable to perform specific 

344 key functions on the apps that let him import, compare, and aggregate data from multiple cloud 

345 sources, limiting his ability to explore the data creatively. This reduces both his value to the 

346 agency and the intrinsic reward he gets from his job.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

5

347 3. From Use Cases to Barrier Categories

348

349 The next step in our analysis is to translate use cases like the ones listed above into a small set 

350 of barrier categories experienced specifically in cloud computing environments.

351 Although cloud computing has changed the landscape in ICT, the current consensus is that its 

352 unique accessibility implications are often minimal. That is, accessibility is more concerned with 

353 the user interface than the infrastructure on which that interface runs, the processes to which 

354 data is subjected, or the content the interface provides a port into. To an end user, whether the 

355 computing environment is cloud-based or not may often be invisible or secondary to the 

356 accessibility barriers encountered in the direct user experience. Taking that into account, the 

357 CCA-PWG identified a few issues that are unique to managing accessibility in the cloud:

358 3.1. Version control

359 Changes to cloud computing software (e.g., fixes and updates) are generally controlled by the 

360 provider, rather than an explicit part of customer enterprise operations management. This can 

361 result in unexpected accessibility jeopardies to users who may not be able to roll back the 

362 changes.

363 3.2. Reliance on browser

364 When cloud computing involves a browser rather than direct use of a cloud app, it inserts an 

365 additional link in the ‘accessibility value chain’, the sequence of technologies that must 

366 successfully interoperate for the appropriate accessibility features to reach the user. For 

367 example, conventional computing may link an operating system, a screen reader, and a 

368 spreadsheet program; a comparable cloud computing chain consists of an operating system, a 

369 screen reader, a browser, and a cloud-based spreadsheet. Note that browser interposition is not 

370 always a negative; browser settings such as enlargement and browser-based screen readers are 

371 sometimes easier to find and use than other options.

372 3.3. Platform quandary

373 Cloud computing is intended to simplify ICT operations in part by reducing the need for 

374 enterprises to provide dedicated support for too wide a range of platforms and operating 

375 systems. In general, this is good for accessibility in that savvy users can select and become 

376 expert in the platform that provides the best accessibility. However, it may unintentionally 

377 jeopardize non-expert users with disabilities who may have difficulty navigating the complicated 

378 decision space, while also not being able to rely on enterprise-supported ICT. For example, an 

379 employee who is permitted to use a personal device (‘bring your own device’ or BYOD) for work 

380 may have difficulty identifying which device (and version, and workplace applications, and 

381 utilities, and assistive technologies...) will best fit both the workplace requirements and his/her 

382 own accessibility needs.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

6

383 3.4. Use of thin clients

384 The advent of cloud computing has brought the use of thin and very thin clients back into use. 

385 These are characterized by terminals that collect input (keyboard, mouse) and display output 

386 (screens), but leave all the computing to be performed at the other end. In fact, this is what 

387 many people think of what is essentially different about cloud computing – that the actual 

388 computing occurs in a network, not in a desktop or other user-facing device. If this includes 

389 having the screen rendered at the other end (and just the image sent back to the terminal) then 

390 many assistive technologies will not work. In particular screen readers (which would have to run 

391 on the remote server to access the screen information) suffer from control and audio delays 

392 that can significantly affect performance and use. Screen enlargers can be almost unusable if 

393 run on the remote server – and have no access to screen information for tracking if run on the 

394 local terminal. Other AT also may have to be installed and run on the remote servers – meaning 

395 that a person may have to have their AT installed on many servers instead of just on their 

396 personal terminal/computer. 

397 3.5. Rich data visualizations

398 Dynamic data (e.g., weather) and large datasets are being used to create visualizations that 

399 make it easier for a sighted user to understand what’s going on. Both the data and the 

400 processing are in the cloud, often due to client-side limitations. Since these are dynamic, the 

401 usual accessibility solutions such as static alt text, longdesc, or ARIA may not be possible, and no 

402 resources are widely available for creating on-the-fly alternatives. Sometimes the visualizations 

403 go beyond the complexity of the data. That is, if a screen reader user had access to the data 

404 he/she might be able to make sense of it, but the visualization is the only access provided.

405 4. Applications Categories and Accessibility Guidance

406

407 The next step of the analysis is to examine cloud computing applications to understand where 

408 and how they cause or prevent accessibility barriers. We begin by roughly categorizing them. 

409 There are many kinds of cloud computing products, services, and features. To enumerate or 

410 catalog them is beyond the scope of this document. However, it is possible to categorize the 

411 most frequently used applications according to functionality as listed below. Note that, as is 

412 characteristic for cloud computing, many of these functions can be and are performed on a 

413 user’s device, via a browser or app, or completely in the cloud. From a user perspective it is not 

414 necessarily important to understand the exact location of any computational function, since the 

415 user’s experience is the result of the entire end-to-end interoperation. However, some of the 

416 following functions are more purely ‘cloud’ than others.

417 • Enterprise collaboration tools – email, calendaring, messaging, document co-editing, 

418 webinar platforms and related real-time collaboration tools

419 • Resource/budget planning/management and project management tools
NIST SP 500-317 Cloud Computing Accessibility Considerations 

7

420 • Customer relationship management (CRM), including customer support and 

421 documentation

422 • Web server/Content Management Systems (CMSs)

423 • Identity management

424 • Document retrieval/Library systems/Online storage

425

426 Many of the technology products and services associated with these functions are designed to 

427 be used in many situations, by many different types of users, for different purposes. That is, 

428 even a specific product like a project management tool is intended for flexible use, and has a 

429 wide range of capabilities, which are normally tailored down for a given environment of use. For 

430 many of these situations, the pathway to solution begins with identifying the specific goals in 

431 the environment of use.

432 To take one of the use cases we identified earlier, consider Garrett’s situation. Part of his 

433 problem could be identified as pertaining to the mobile platform he uses. Selecting the right 

434 platform for his needs, that also meets agency platform compatibility and operational realities, 

435 is highly complex and rapidly evolving. One solution to part of his difficulty might be solved if he 

436 could view his current task at the same time as seeing the exchange of text messages with his 

437 supervisor, instead of having to shift back and forth between applications. An update to his 

438 current platform’s operating system may permit such multi-tasking directly, or indirectly via a 

439 simple gesture swapping between applications. 

440 We will discuss later how information resources play an essential role in solving specific 

441 accessibility problems. For now, we focus on the use case to develop the point that although 

442 accessibility must be considered globally during procurement and development, it must be 

443 managed locally during use. For Garrett, this means that identifying the specific function of 

444 “seeing the task and the message thread at the same time” is a requirement for successful use.

445 Appendix B provides some specific guidance on some of these application categories in addition 

446 to general guidance on cloud computing. We emphasize that for reasons of accuracy, 

447 comprehensiveness, and especially harmonization, those looking for technological guidance 

refer first to the Web Content Accessibility Guidelines (WCAG 2.03 448 ); not only the Guidelines 

449 themselves, but the whole ecosystem of Success Criteria and other material provided there.

450

 

3 http://www.w3.org/TR/WCAG20/
NIST SP 500-317 Cloud Computing Accessibility Considerations 

8

451 5. New Cloud-Based Accessibility Opportunities

452

453 So far, this document has focused on how cloud computing either replicates or exacerbates 

454 accessibility problems found in previous computing environment models. But cloud computing 

455 offers new and exciting accessibility opportunities, not just new problems. This section describes 

456 two of the most promising.

457 5.1. Global Public Inclusive Infrastructure (GPII)

The GPII4 458 is a global multi-year program to build an accessibility infrastructure in the cloud. The 

459 GPII will allow people who have problems with standard interfaces and content – all of us, in 

460 some situation or other – to be able to use information and communication technology (ICT) 

461 products and services anywhere they encounter them. It will allow users to invoke the interface 

462 and content adaptations they want or need, automatically, on any device, anywhere, anytime.

463 The purpose of the GPII is to ensure that everyone who faces ICT barriers due to disability or 

464 usability issues, literacy, digital literacy, or aging, regardless of economic resources, can access 

465 and use the Internet and all its information, communities, and services for education, 

466 employment, daily living, civic participation, health, and safety.

467

468 The GPII will encompass a family of tools and services:

469

470  Tools for users to explore, select, store, and manage their preferences – the features 

471 they want or need for interfaces and content

472  Ways to match those user needs and preferences with the capabilities of the devices 

473 users encounter: public computers, websites, online videos, transaction machines, etc.

474  Ways to negotiate and implement those preferences on the user’s current device, in 

475 real time – “automatic personalization”

476  Development tools to let assistive technology and mainstream companies, commercial 

477 and non-commercial, build or adapt their accessibility software and services into the 

478 cloud, including ways for them to reach and serve more potential users

479  Management tools so that all participating entities – consumers, software companies, 

480 AT funding agencies, ATM manufacturers, educators, employers, retailers, etc. – can be 

481 assured of highly reliable, effective, secure, private, efficient, and manageable 

482 accessibility solutions.

483

484 The GPII will not create new access technologies or services itself. It is the infrastructure for 

485 making their development, identification, delivery, and use easier, less expensive, and more 

 

4 http://gpii.net
NIST SP 500-317 Cloud Computing Accessibility Considerations 

9

486 effective. This is similar to building a road system; roads do not provide transportation but 

487 greatly enhance the ability of car companies and others to do so. They provide an infrastructure 

488 that car companies themselves cannot make. The Internet is the infrastructure for general 

489 information and commerce. The GPII enhancements to the Internet will enable the Internet to 

490 be truly inclusive for the first time.

491

492 We have an unprecedented opportunity to fundamentally change and advance accessibility – to 

493 create an infrastructure that supports both commercial and non-commercial efforts to make 

494 accessibility more affordable, to reach more of the people who need it than the estimated 3 -

495 15% we reach now, to make it all simpler, to serve disabilities and aging groups we don't now 

496 serve or serve well, and to build access that will work with the new technologies that are 

497 coming.

498

499 The implications for US federal cloud computing are powerful. The GPII will offer federal entities 

500 an integrated method to meet the needs of both employees and members of the public, as 

501 required by Section 508 and other laws, with greater confidence and lower cost. In order to 

502 redeem this promise, planning for federal cloud computing should factor in the development 

503 and implementation of the GPII as one of the solution paths agencies can travel. Policies and 

504 tools that NIST is building as part of its cloud computing roadmap responsibilities can help bring 

505 accessibility into the mainstream of federal ICT where its impact is greater and costs are lower; 

506 the GPII can be a significant part of that effort.

507 5.2. Accessibility Application Programming Interfaces (AAPIs)

508 An accessibility application programming interface (AAPI) is any capability built into an operating 

509 system or platform that provides developers with the necessary software interface for 

510 accessibility features such as screen reading and magnification. For example, the iOS platform 

511 provides global screen reading and magnification capabilities as a default for all apps developed 

512 on that platform. This vastly simplifies and standardizes accessibility solutions. AAPIs may not 

513 have originally been intended for promoting accessibility features, but have that effect, which is 

514 a natural outgrowth of ‘responsive design’ aimed at serving the wide range of mobile devices.

515

516 A persistent challenge for computer accessibility has been the limited adoption of accessibility 

517 APIs by developers. Many developers perceived limited benefits to incorporating accessibility 

518 APIs into their products. In the desktop era, software ran on a single device in a single context 

519 (i.e., a desktop computer in an office) and the vast majority of users could use software without 

520 the need for any adaptations. In the laptop era, software ran on two similar devices (desktops 

521 and laptop computers) in a larger number of contexts, but the need for adaptations by most 

522 people was still limited. The advent of cloud computing, in combination with mobile computing 

523 devices (e.g., tablets, smartphones), has created an environment where the same software 

524 can run on multiple devices with very different input and output capabilities and a wide variety 

525 of use contexts (e.g., while driving; while walking; one-handed; in a noisy environment; in direct 

526 sunlight). Developers adopt tools like HTML5 and CSS3 because they offer the promise of 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

10

527 the same software running across multiple devices. Developers should similarly adopt 

528 accessibility APIs because they allow software to run in multiple contexts. Developers who want 

529 their product to have a competitive advantage because users can access it in their office (on a 

530 computer), in their living room (on a tablet) and out and about (on their smartphone) regardless 

531 of where they are, what else they are doing and what is going on around them, but don't want 

532 to implement all these capabilities from scratch, should use cloud computing, cloud storage, 

533 non-native code and accessibility APIs. In this environment, accessibility should not be perceived 

534 as an obligation or additional requirement, but rather as a fundamental aspect of software 

535 development and a selling-point for a product.

536

537 Understanding the accessibility-related benefits of APIs allow system developers, system 

538 owners, and other stakeholders to modernize their systems in ways that benefit all 

539 stakeholders. 

540

541 For example: 

542

543 1. Accessible Ports-of-Entry: APIs can significantly leverage the ability to develop fully544 accessible "ports-of-entry" to cloud-based resources.

545

546 2. Efficiency: API access allows content to be created one time in a manner that can 

547 enable developers to make it accessible and available through many channels. 

548

549 3. Wider Reach: By allowing anyone to create new presentation layers, like a 

550 mobile/computer-based applications and websites, APIs can be used to create services 

551 and information that is fully-accessible to people with disabilities.

552

553 4. Distribute Services and Information to New Audiences: APIs can be used to distribute 

554 services and information to new audiences and in specific contexts that can be 

555 customized to meet the access needs of individual consumers. 

556

557 5. Leverage Government Assets: Data and information produced by the federal 

558 government is a national asset, paid for by the American people. APIs can expose data 

559 that was only available to a few and make it more available to everyone, including 

560 people with disabilities. 

561

562 6. Automation: APIs allow machines to handle workloads which might otherwise require 

563 the manual work of a human being. This can be as simple as having one content update 

564 propagate to multiple sections of an accessible website (or multiple accessible websites) 

565 at once. 

566

567 7. Application: Providing API access to information or a service sets up the use of that 

568 information or service by accessibility experts developing mobile apps. This is especially 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

11

569 beneficial if an organization plans to build more than one app. APIs can serve as a 

570 shortcut to developing an accessible second, third, and fourth app. 

571

572 8. Partnerships: The mission of every agency is supplemented by like-minded non-profits 

573 and businesses, who are interested in using agency information and services to provide 

574 services. They do this by consuming and repurposing agency material into new, useful 

575 products and putting agency content in front of their customers and clients. Enabling 

576 businesses to easily create accessible interfaces to government information can fuel 

577 innovation. 

578

579 9. Increasing Efficiency and Reducing Cost: If developers plan to develop more than one 

580 resource, APIs can serve as a shortcut to developing additional ones.

581

582 10. Integration: APIs allow content to be more easily embedded or interwoven throughout 

583 websites and applications. It can help to ensure smooth, integrated, and accessible user 

584 experiences.

585

586 11. Personalization: Users of government websites can benefit from the ability to 

587 personalize and enhance the accessibility of sessions with the information and services 

588 that are most useful to them. 

589

590 12. Mashups: Mashups allow the public to better understand government information in 

591 the context of other sources of information. An agency service or data stream can be a 

592 small, important part of another service... especially if it is easily mashed-up and made 

593 accessible. 

594

595 13. Future-Ready: As needs change, APIs can help to support unanticipated future uses in 

596 manners that make it easier to render deliverables in an accessible manner.

597 6. The Role of Information Resources

598

599 At the beginning of 2014, the CCA-PWG turned to a separate but related issue in cloud 

600 computing accessibility. As can be seen in several of the use cases above, some accessibility 

601 problems are caused by a lack of information in the right hands at the right moment, rather than 

602 the total absence of a technological solution. In Garrett’s case, we suggested that his agency 

603 keep an eye on the mobile environment to learn when that marketplace offers a mainstream 

604 solution to a key requirement, Garrett’s need to see both his task and texts from his supervisor 

605 at the same time. Can his organization survey the mobile environment itself to discover this 

606 capability? If it cannot do this itself, can it learn from others, in the federal space or elsewhere, 

607 about emerging solutions?
NIST SP 500-317 Cloud Computing Accessibility Considerations 

12

608 Finding accurate, timely, situationally-relevant information about accessibility is not trivial. 

609 Although new features constantly pop up across the horizon of products and services, their 

610 accessibility implications are not usually highlighted or reported broadly or consistently. The 

611 speed and churn of modern mainstream ICT makes curating accessibility solutions challenging 

612 even to full-time accessibility professionals, let alone the many more part-timers, including 

613 people with disabilities themselves, who must identify and resolve specific problems with fewer 

614 resources at hand.

615 However, this is a known problem. Efforts have been and are being made to address the need 

616 for better information resources about accessible ICT.

617 6.1. Example: the FCC's Accessibility Clearinghouse

The FCC's Accessibility Clearinghouse5 618 is a web repository of information about accessible 

619 communications products and services. It is mandated by the 21st Century Communications 

620 and Video Accessibility Act of 2010 (CVAA), which also requires the FCC to promote this resource 

621 to the public. The Accessibility Clearinghouse includes information on the following topics:

622  Accessibility features of mobile phones

623  Accessibility contacts at telecommunications and advanced communications services 

624 companies

625  Free assistive apps for various computing platforms

626  Organizations implementing the National Deaf-Blind Equipment Distribution Program 

(NDBEDP)6 627 .

628

629 To enable more flexible and targeted use of Clearinghouse information, the FCC has released a 

software development kit (SDK; blog post7; source code8; demo video9 630 ) that makes custom 

631 programming of inquiries to the database relatively easy with a free, popular language called 

632 Python. Python-based apps can query the Clearinghouse based on an application programming 

633 interface (API). Clearinghouse Information may be selectively filtered and combined with data 

634 from other sources as mashups. Views of information may be created that differ from the 

635 presentation on the Clearinghouse website, thereby tailoring value for particular constituencies 

636 or devices.

 

5 http://www.fcc.gov/accessibilityclearinghouse

6 https://www.fcc.gov/general/national-deaf-blind-equipment-distribution-program

7 http://www.fcc.gov/blog/fcc-releases-software-development-kit-accessibility-clearinghouse

8 http://www.github.com/FCC/clearinghouseSDK

9 http://www.youtube.com/watch?v=_Pk0igOFmqY
NIST SP 500-317 Cloud Computing Accessibility Considerations 

13

637 7. Cloud Computing Accessibility Taxonomy

638

639 In order to create information resources that make sense to their users, it is essential to have 

640 consistent frameworks and terms. Using the API model of aggregation, it is possible for 

641 information resources to be shared such that a search of one reveals findings originally collected 

642 by another. This consistency and cross-communication promise greater efficiency on the input 

643 side, and greater usage on the output side.

644 The CCA-PWG decided to initiate research into accessibility taxonomies, in order to clarify what 

645 these opportunities might look like, and how they could be achieved.

646 7.1. Audiences and Goals

647 We begin the analysis with an attempt to understand who potential taxonomy users are and 

648 what their goals are.

649 Developers. Technology designers and developers need to have clear guidance and a suitable 

650 software framework for building accessibility into their products. In these cases taxonomies act 

651 as pointers to accessibility settings or libraries.

652 Content creators. Similarly, content creators (especially in the education field) need a 

653 standardized way to categorize their content to indicate the accessibility features it contains, 

654 such as captions, so that users can find what they need.

655 Users with disabilities. People with disabilities who are searching for ICT with the accessibility 

656 features they need would benefit from a taxonomical framework that supports intelligent 

657 search via common terminology. A key dimension would be functional limitation.

658 Practitioners. Similarly, special educators, therapists, and others would benefit from a 

659 framework that reflects their professional practice.

660 Technology managers. Enterprise staff such as accessibility program managers and ICT 

661 administrators would benefit from a taxonomy that could be used to inform the ICT 

662 procurement process. For example, a school district technology coordinator would be able to 

search the market for 7th 663 grade science textbooks that have alternative formats; a CIO office 

664 could identify workplace ICT likely to have the features needed by a new job applicant.

665 Policy makers. An appropriate taxonomy could aid in evaluating gaps in the accessibility market 

666 and planning for their resolution, using market or regulatory tools. For example, Section 508 

667 Voluntary Product Accessibility Templates (VPATs) are in a sense a regulatorily-driven taxonomy 

668 of accessibility features as applied to different technology families. Aggregated VPATs could be 

669 used to analyze the range of accessibility features and solutions found in the market, without 

670 having to perform a ‘census’ of technologies actually in use.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

14

671 Clearly, the needs of these audiences are not identical, but there is substantial overlap. A clear 

672 taxonomy that arranges features by technology platform would benefit both developers and 

673 consumers in search of a new product. A taxonomy that is well documented would serve as an 

674 excellent introduction to the field of accessible technology for newcomers of all audiences.

675 One important distinction might be between audiences that can be characterized as supply-side

676 (developers and authors) and demand-side (users with disabilities, AT/accessibility practitioners, 

677 technology managers, and policy makers). The former would use a taxonomy to identify and 

678 organize the accessibility work that needs to be done, find components that assist in developing 

679 accessible products, track the progress/features of the competitors, or report their progress 

680 within a product development process. The latter would use a taxonomy to identify products 

681 and features they may need (directly or indirectly), or to manage technologies organizationally 

682 (e.g., procurement oversight) or regulatorily. Most importantly, the needs of a developer-facing 

683 taxonomy in terms of technical complexity and code-friendliness (some entries should work like 

684 source code snippets) may require separate taxonomies or audience-targeted renderings of a 

685 unified taxonomy. 

686 Another distinction is worthwhile. ‘Pre-sale’ resources would help people in the market make 

687 their decisions; these resources would highlight the differences among comparable products in 

688 terms of features and functions. ‘Post-sale’ resources would cover how a given ICT product or 

689 service, already in use, can be used most accessibly. Such a resource would include workarounds 

690 for AT compatibility issues, application notes, third-party utilities, and might even have a user 

691 group.

692 7.2. The Dimensions

693 Given those audiences and goals, here are the dimensions of categorization that may prove 

694 useful, with the potential benefits:

695 Disability category / human performance modality, such as “vision” and “hearing”, either 

696 referring to the disability or to the performance modality. This will allow consumers with 

697 disabilities to search for products and features of interest to them, and specialized practitioners 

698 (e.g., speech therapists) to focus on their professional scope. There are often objections to this 

699 dimension, in that it can ‘medicalize’ accessibility instead of focusing on user needs and 

700 preferences, and also that it can limit the application of some features to a single disability 

701 category (e.g., ‘text-to-speech’ categorized under ‘blindness’).

702 Context of use, such as “education” and “employment”. This will allow both supply- and 

703 demand-side users to focus in on specific use environments for context-dependent details on 

704 availability, features, application notes, etc.

705 Technology platform. This will allow both supply- and demand-side users to focus in on 

706 platforms (e.g., a specific operating system) already selected or out of their control.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

15

707 Technology product, function and/or feature, both mainstream and AT. This is really the core of 

708 a useful taxonomy, for all audiences: the categorization of specific product features and 

709 functions, whether they are explicitly accessibility features or not. The comprehensiveness of 

710 the lists and their sound categorization are essential components. In many cases the product or 

711 product category will be a separate dimension. 

712 Legal/regulatory coverage. All potential users would benefit from understanding where certain 

713 features or products are required by law, in which jurisdictions. Note that information in this 

714 dimension may relate to the environment of use. For example, a law may require captioning for 

715 resources used in elementary education.

716 Appearance in a standard. The benefit is largely for supply-side users, letting them align their 

717 work with specific technical standards.

718 AT vs. mainstream product. This would provide information about availability of funding in 

719 some circumstances.

720 Note that categorization within these dimensions should not be exclusive. For example, an 

721 accessibility solution should be appear in all contexts of use in which it provides benefit.

722 Appendix D is a collection of taxonomies the CCA-PWG analyzed.

723 7.3. Draft Taxonomy

724 The schema below is based on the following primary criteria, extracted from the above 

725 discussion of potential audiences and dimensions of interest:

726  Intended for an audience of users and managers rather than developers. In general this 

727 means a focus on the result of a feature rather than how it is implemented, as well as 

728 substantially less complexity.

729  Intended to aid in product selection. This is a key point. This taxonomy does not 

730 exhaustively identify differences in features between products. Rather it aims to place 

731 its user in the position of being able to identify a small enough set of candidate products 

732 so that he/she can then proceed to evaluate those products directly in order to make an 

733 informed selection.

734  Capable of categorizing features as well as products. Some users will be in search of a 

735 product, while some will be seeking information on how to implement a feature within a 

736 product.

737  Useful as a rough educational guide to the domain of accessible ICT. Naïve users should 

738 be able to get an idea of how the field of accessible ICT is structured.

739
NIST SP 500-317 Cloud Computing Accessibility Considerations 

16

740 Overall, the Raising the Floor/Consumer Electronics Foundation taxonomy fits these criteria 

741 best. The draft below differs from it significantly, however, partly just in order to explore an 

742 alternative structure, but largely to demonstrate a difference due to the second criterion 

743 identified above: focusing more on the product selection process than on exhaustive 

744 description.

745

746 7.4. Taxonomy Mind Map

747

748 The nominal Cloud Accessibility taxonomy is depicted in this list and attached MindMap figure 

749 which shows the 5 following major headings (nodes).

750

751  Audio & alternatives

752 o Assistive listening system

753 o Audio enhancement

754  Amplification

755  Noise reduction/clarification

756 o Captions & transcription

757  Real-time

758  Stored

759 o Remote & relay services

760  Sign language relay (video relay service or VRS)

761  Remote sign language interpreting (video remote interpreting or VRI)

762  Text relay

763

764  Control, input & operation 

765 o Alternative computer input device or system

766  Alternative keyboard, including on-screen

767  Alternative mouse or pointer

768  Keyboard-only control

769  Morse code

770  Scanning

771 o Error prevention

772  Auto-correction

773  FilterKeys etc.

774 o Gesture recognition

775  Camera-based

776  Dynamic/multi-touch touchscreen or tablet

777 o Prediction, expansion & macros

778  Abbreviations

779  Macros

780  Prediction

781 o Speech recognition 

782  For computer control

783  For text and other input

784
NIST SP 500-317 Cloud Computing Accessibility Considerations 

17

785  Reading, understanding, learning & managing

786 o Coaching, assistance 

787  Help in context

788  Notification of and communication with others, including caregivers

789 o Learning & understanding 

790  Contextualization (breadcrumbs, etc.)

791  Dictionaries, glossaries, translations, etc.

792  Simplified versions

793  Summaries

794 o Reading

795  Highlighting

796  Re-formatting for ease of reading

797  Text-to-speech

798 o Scheduling & reminding

799  Calendars

800  Notifications

801  Prompting

802

803  Speaking & communicating

804 o Communication aids (devices or software)

805  Image/ icon-based

806  Text-based

807 o Speech-to-speech relay

808

809  Visual & alternatives

810 o Alternative text & video description 

811 o Braille & tactile 

812 o High contrast & readability

813 o Magnification

814 o Text-to-speech 

815  Screen reader
NIST SP 500-317 Cloud Computing Accessibility Considerations 

18

816

817 Figure 1 - Cloud Accessibility MindMap

818
NIST SP 500-317 Cloud Computing Accessibility Considerations 

19

819 8. Conclusions

820

821 The work of the CCA-PWG to this point has been to identify specific areas where cloud 

822 computing offers both opportunities and jeopardies to accessibility. In many ways, cloud 

823 computing is identical, from a user experience perspective, to conventional computing. 

824 However, we did identify several barrier categories that are unique to cloud computing, as it is 

825 being implemented, by collecting and analyzing a small set of use cases. These often point to the 

826 need for non-technological as well as technological solutions.

827

828 Regarding guidance, we emphasize the importance of relying on WCAG 2.0 as both a primary 

829 source and a rallying point for the accessibility communities of practice, but we do present some 

830 specific guidance for a few key categories of cloud computing products and services.

831

832 We also studied two cloud-based approaches to accessibility, the use of accessibility APIs, and 

833 the Global Public Inclusive Infrastructure.

834

835 The CCA-PWG recognized the need for better information resources about accessibility, and

836 took upon itself some formative research about how current information resources organize the 

837 material – their taxonomies. After analyzing a large but not exhaustive set in terms of their 

838 audiences and domains of application, we created a draft taxonomy that could be used 

839 specifically on cloud computing.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

20

840 Appendix A: Comments from Raising the Floor – International on "US 

841 Government Cloud Computing Technology Roadmap, Release 1.0 (Draft)"

842

843 3 December 2011

844 A1. Introduction

Raising the Floor – International10 845 is grateful to the National Institute of Standards and 

846 Technology for this opportunity to comment on its Cloud Computing Roadmap (SP 500-293, 

847 Volumes I and II). Our comments will only cover the issue of accessibility for people with 

848 disabilities, from 2 perspectives:

849  General accessibility of cloud computing resources

850  The potential for the Global Public Inclusive Infrastructure (GPII) to address accessibility

851

852 We hope that our comments can be useful in refining the document, and in the follow-on work 

853 of developing policies for implementing cloud computing in the federal environment.

854 We are available to provide explanation and/or detailed content for any of these 

855 recommendations.

856 A2. General Accessibility Comments

857 The Roadmap mentions accessibility at a few points, notably in Volume I as an example in 

858 Section 3.4, “Interdependency with Other National Priority Initiatives”. However, we feel that 

859 accessibility should be emphasized more in the document. We note that the Roadmap 

860 consistently addresses 3 cross-cutting requirements: security, interoperability, and portability. If 

861 accessibility cannot be ‘promoted’ to this same level of salience, it should at least be dealt with 

862 in greater detail. Below we suggest some places where this may be appropriate.

 

10 Raising the Floor (RtF – http://raisingthefloor.org) is an international non-profit organization whose 

mission is “to make the web and mobile technologies accessible to everyone with disability, literacy and 

aging-related barriers, regardless of their economic status.” To this end, RtF participates in an 

international technology development program, the Global Public Inclusive Infrastructure (GPII –

http://gpii.net). GPII is a cloud-based system for ICT personalization, so that the interface needs of any 

given person with a disability can be implemented automatically on any ICT device or service.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

21

863 Table 1: Comments on NIST SP 500-293 Volume I with respect to Accessibility

Roadmap Section & Relevant Text for Volume I Suggestion

2.1 Requirement 1: International Voluntary ConsensusBased Interoperability, Portability & Security Standards

“Government, industry, and other stakeholders need to 

define requirements, develop international voluntary 

consensus-based interoperability, portability and security 

standards, and implement them in products, processes and 

services.”

Add references to accessibility 

standards such as W3C’s 

WCAG, UAAG, and ATAG.

See Appendix C.

2.3 Requirement 3: Technical Specifications for High-Quality 

Service-Level Agreements

Industry and USG need to develop and adopt consistent 

technical specifications, of high quality and completeness, 

to enable the creation and practical evaluation of ServiceLevel Agreements (SLAs) between customers and cloud 

providers.

This is the right place to include 

accessibility requirements & 

standards

This requirement mentions 

using a standardized 

vocabulary (1st Priority Action 

Plan). It would be useful to 

clarify the meaning of 

“accessibility”, distinguishing 

the disability-oriented usage 

from the technical usage where 

it refers to the availability of a 

facility (e.g., “The database is 

accessible via standard 

browsers.”)

2.7 Requirement 7: Defined Unique Government 

Requirements and Solutions

Why: In addition to policy related to cloud services 

adoption, USG agencies are subject to policy and regulatory 

requirements, which are unique to government agencies. 

Government agencies must ensure that cloud services and 

products meet these policy and compliance requirements 

as well as mission functionality. Although agencies use 

commercial services to complete key elements of their 

mission, USG agencies cannot delegate inherently 

governmental federal authorities and public trust 

responsibilities to the private sector. USG institutions 

cannot mitigate risk through commercial means (e.g., 

financial penalties, insurance, litigation) to the same degree 

as private sector organizations. Failure to recognize and 

address government constraints may slow the adoption of 

cloud services.

A reference to Section 508 and 

other accessibility laws and 

regulations that target the 

public sector should be 

included here. The purpose of 

the reference is to indicate that 

cloud computing is subject to 

Section 508, and that 

accessible cloud computing can 

be an efficient way to address 

Section 508.

864
NIST SP 500-317 Cloud Computing Accessibility Considerations 

22

865 Table 2: Comments on NIST SP 500-293 Volume II with respect to Accessibility

Roadmap Section & Relevant Text for Volume II Suggestion

2.2.2.3 Cloud Auditor

A cloud auditor is a party that can perform an independent 

examination of cloud service controls with the intent to 

express an opinion thereon. Audits are performed to verify 

conformance to standards through a review of objective 

evidence. A cloud auditor can evaluate the services 

provided by a cloud provider such as security controls, 

privacy impact, and performance

Add a reference to audits 

undertaken to assess 

accessibility.

4.3 Accelerating the Development and the Use of Cloud 

Computing Standards

Each of the recommendations 

below has implications for 

accessibility in its detailed 

implementation.

Recommendation 1 – Contribute Agency Requirements

Agencies should contribute clear and comprehensive user 

requirements for cloud computing standards projects.

Note: in addition to general 

Section 508 requirements, 

some agencies have their own 

additional requirements

Recommendation 2 – Participate in Standards Development

Agencies should actively participate in cloud computing 

standards development projects that are of high priority to 

their agency missions.

One possibility would be to 

identify a lead agency for 

accessible standards 

development.

Recommendation 3 – Encourage Testing to Accelerate 

Technically Sound Standards-Based Deployments

Agencies should support the concurrent development of 

conformity and interoperability assessment schemes to 

accelerate the development and use of technically sound 

cloud computing standards and standards-based products, 

processes, and services.

These assessment schemes 

should include deep evaluation 

of accessibility; identification of 

accessibility barriers should be 

reported back to the vendor 

and/or SDO.

Recommendation 4 – Specify Cloud Computing Standards

Agencies should specify cloud computing standards as a 

factor in procuring cloud services and assess cases when 

multiple vendors offer standards-based implementations 

and there is evidence of successful interoperability testing. 

In such cases, agencies should ask vendors to show 

compliance to the specified standards.

Accessibility standards such as 

ISO 24751 should be included.

This Recommendation could 

also refer to other aspects of 

the procurement process, and 

the forms and checklists used –

this is another aspect of 

Section 508 oversight and 

management.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

23

Roadmap Section & Relevant Text for Volume II Suggestion

Recommendation 5 – USG-Wide Use of Cloud Computing 

Standards

To support USG government requirements for 

interoperability, portability, and security in cloud 

computing, in coordination with and under the cognizance 

of the federal Enterprise Architecture program, the Federal 

Standards and Technology Working Group should 

recommend specific cloud computing standards for USGwide use.

Accessibility standards such as 

ISO 24751 should be included.

Recommendation 6 – Dissemination of Information on 

Cloud Computing Standards

A listing of standards relevant to cloud computing should 

be posted and maintained.

Accessibility standards such as 

ISO 24751 should be included.

866

867 A3. Global Public Inclusive Infrastructure

868 The Global Public Inclusive Infrastructure (GPII - http://gpii.net) is an international program to 

869 develop cloud-based automatic personalization of user interfaces and user context adaptation 

870 based on user preferences. From the GPII website: “Each ICT device will be able to instantly 

871 change to fit users as they encounter the device, rather than requiring users to figure out how 

872 to adapt, configure or install access features they need.” GPII cloud elements will store user 

873 preference profiles, accessibility solutions, and information about matching needs to device 

874 capabilities in context.

875 Several federal agencies have indicated an interest in being early adoption sites for GPII, and the 

876 program itself receives significant federal support.

877 We see a need to integrate GPII into federal plans for cloud computing implementation. We 

878 believe that this integration will improve the accessibility of federal ICT resources for both 

879 employees and members of the public, and the efficiency of doing so.

880

881 There are 2 specific sections in Volume I of the Roadmap where we feel a reference to GPII is 

882 warranted:

883

884 Table 3: Comments on NIST SP 500-293 Volume I with respect to GPII

Roadmap Section Suggestion

2.5 Requirement 5: Frameworks to Support Federated 

Community Clouds

Industry and the USG need to develop frameworks to 

support seamless implementation of federated community 

cloud environments. (interoperability and portability 

guidance and technology)

In one scenario, GPII is 

implemented locally, as 

“cloudlets” within 

organizational firewalls. Add a 

reference to GPII as an 

example.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

24

2.8 Requirement 8: Collaborative Parallel “future cloud” 

Development Initiatives

Academia, industry, and USG need to initiate parallel 

―future cloud‖ development initiatives. (interoperability, 

portability, and scalability technology)

Add a reference to GPII as one 

arena in which this 

collaborative development may 

occur.

885

886 As the Roadmap is implemented, and in other related federal cloud computing initiatives, we 

887 hope to offer GPII as an integrated solution.

888 A4. Other Recommendations

889 Volume I Section 1.2 and Volume II Section 1.3 recognize that the audience for the Roadmap 

890 includes agency CIOs and the US Federal CIO Council. The CIO Council has an Accessibility 

891 Committee; this Committee should be referenced in the document as a resource for 

892 implementing accessibility in cloud computing, along with points of contact for the Committee 

893 and its Subcommittees.

894

895 NIST itself has accessibility resources that should be brought to bear in elaborating and 

896 implementing the Roadmap, especially in standards development. NIST resources and their 

897 points of contact should be referenced in the Roadmap and explicitly supported for this role.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

25

898 Appendix B: Guidance for Cloud Computing Accessibility

899 As stated in the body of this report, excellent accessibility guidance is available through WCAG 

900 2.0 and the corresponding Section 508 regulations, currently (March 2015) under revision to 

901 bring it into close harmonization with WCAG 2.0.

902 This section will describe a set of general guidelines for accessibility for each of the application 

903 categories and discuss the utility of cloud computing which can alleviate the issues related to 

904 accessibility.

905 B1. General Guidelines

906 In general, cloud computing accessibility guidance will align very closely with other computing 

907 environments, since most accessibility implications concern the user interface rather than back908 end processing. For reasons of clarity and harmonization, we suggest that both technology 

909 developers and managers refer to WCAG 2.0 for details.

910 However, there is the potential for cloud-specific guidance that can be attached to the cloud911 specific barrier categories we described above. 

912 1) Applications should not block the device’s accessibility features.

913 a) Many devices have built-in accessibility features. Users should be able to utilize these 

914 features within the application. Some of these features include:

915 i) Zoom / Screen Magnification / Large Type

916 ii) Voice Commands / Dictation

917 iii) Voice Over / Speak Selection

918 iv) Screen reading and Navigation, Braille displays?

919 v) High Contrast/color customization for people who are color blind

920 vi) Subtitles / Closed Captions

921 vii) Hearing Aid Compatibility

922

923 2) Applications should provide multiple methods for users to create, read, update and delete 

924 information.

925 a) User should be able to access software and devices to create, read, update and delete 

926 information. Some of these include:

927 i) Screen Readers

928 ii) Refreshable Braille Displays

929 iii) Speech Recognition Software

930 iv) Text-to-Speech (TTS) Synthesizers

931 v) Screen Magnifiers/Zoom

932 vi) Alternative Keyboards

933 vii) Electronic Pointing Devices

934

935 b) User should be able to utilize multiple methods to create, read, update and delete 

936 information. Some of these include:
NIST SP 500-317 Cloud Computing Accessibility Considerations 

26

937 i) Voice Commands

938 ii) Gestures

939 iii) Keyboards (on-screen and add-on)

940

941 c) Focus-based navigation should be enabled so that users can navigate using gestures, 

942 voice commands, screen readers and hardware devices.

943

944 3) Controls need descriptions

945 a) Image buttons, checkboxes and other interface components that do not have visible 

946 text should have text descriptions available. The exception for this is decorative images.

947

948 4) Controls need to be in a logical order

949 a) A user should be able to navigate the application using a hardware device such as a 

950 keyboard or spoken commands (next, previous) in a logical order.

951 b) Keyboard shortcuts should be available to help users navigate. The shortcuts should be 

952 identified by an underscore under the shortcut key (i.e. Save)

953 5) Feedback and Alerts should be provided in multiple formats.

954 a) The user should be able to receive alerts and feedback in multiple formats, set by user 

955 preference. Some of these include:

956 i) Audio alert (beep or ring)

957 ii) Visual alert (flashing light)

958 iii) Tactile alert (vibration)

959 B2. Enterprise collaboration Tools - email, calendaring, IM

960 1) Users should be able to access email content multiple ways (see General Guidelines 2)

961 a) Navigation in an email client should allow the user multiple ways to:

962 i) Move between messages

963 ii) Download new messages

964 iii) Delete one or more messages

965 iv) Scan message headers

966 v) Create a new message

967 vi) Reply to a message (one or all)

968 vii) Set up or delete an email configuration

969 viii) Sort messages (by sender, date, size, attachments, etc.)

970 ix) Search for specific content

971

972 b) Navigation in a calendaring tool should allow the user multiple ways to:

973 i) Create a new event including interact with online databases to invite attendees, 

974 identify available times for multiple attendees, set up reminders and repeated 

975 appointments

976 ii) Delete an event, current and future
NIST SP 500-317 Cloud Computing Accessibility Considerations 

27

977 iii) Scan events

978 iv) Receive alerts for events

979 v) Modify an event (date, time or details)

980 vi) Review attendees responses regarding availability or proposed new times

981 vii) Read items on calendar by date, week, month, and topic

982

983 c) Navigation in an Instant Messaging tool should allow the user multiple ways to:

984 i) Create a new conversation

985 ii) Respond to a conversations including emoticons

986 iii) Identify message senders

987 iv) Move between multiple conversations

988 v) Access and review archived conversations

989 vi) Delete an archived conversation

990 vii) Receive alerts for conversations

991 viii) Identify when individuals are on and off-line

992

993 d) Video messaging should provide a method for vision and hearing impaired users to 

994 participate. Some of these methods include:

995 i) Written transcripts or captions

996 ii) Instant Messaging

997 iii) Chats

998 iv) Confirm when camera is engaged and person in focus by non-visual means

999

1000 e) Audio conferences should provide a method for hearing impaired users to participate. 

1001 Some of these methods include:

1002 i) Written transcripts or captions

1003 ii) Instant Messaging

1004 iii) Chats

1005 iv) Supplemental video interpretation

1006

1007 d) Applications should work with the device's built-in tools and not require additional

1008 downloads or plug-ins

1009 B3. Customer relationship management (CRM)

1010 1) The application should be available to the user while the user is engaged with their customer

1011 f) Fields should be easy to input and edit using multiple input methods. Some of these 

1012 methods include:

1013 i) Voice Commands

1014 ii) Gestures

1015 iii) Keyboards (on-screen and add-on)
NIST SP 500-317 Cloud Computing Accessibility Considerations 

28

1016 B4. Web server / Content Management

1017 1) The application should be accessible to content authors and end users

1018 g) Content authors should be able to easily navigate and:

1019 i) Create new content

1020 ii) Format content

1021 iii) Edit content and read edited content

1022 iv) Delete, retrieve or archive content

1023 v) Move content to a new section

1024

1025 h) End users should have multiple ways to:

1026 i) Search content

1027 ii) Read content, including portions identified by user

1028 iii) Comment in forums or where user feedback is allowed

1029 iv) Identify comments by commenter, as displayed

1030 B5. Identity Management

1031 1) The user should have multiple methods to:

1032 a) Create a profile

1033 b) Sign in

1034 c) Recover a forgotten username

1035 d) Set up a password independently and recover a lost password

1036 e) Update a profile

1037 f) Delete a profile

1038

1039 2) The profile and identity should be separate from user preferences

1040 3) CAPTCHAs are discouraged because they are not accessible

1041 4) A single sign-on is encouraged. This can be via text (username and password), biometrics

1042 (fingerprint, voice recognition, or iris scan), or other method. If a biometric method is used,

1043 an alternate method should be available. SecureID devices will need an accessible

1044 alternative.

1045 B6. Document Retrieval / Library Systems

1046 1) Users should be able to access library content multiple ways (see General Guidelines 2)

1047 a) Navigation in a document retrieval/library system should allow the user multiple ways 

1048 to:

1049 i) Search for documents

1050 ii) Refine search results

1051 iii) Retrieve documents

1052 iv) Read and navigate through content (Headings, tables of content, highlighted 

1053 keywords, etc.) in documents
NIST SP 500-317 Cloud Computing Accessibility Considerations 

29

1054

1055 b) Content should be discoverable and search results should be easy to navigate.

1056 i) If search results span multiple pages, the focus should remain in the results section, 

1057 not returning to the search pane.

1058 ii) Metadata is encouraged to aid in discoverability
NIST SP 500-317 Cloud Computing Accessibility Considerations 

30

1059 Appendix C: The Role of Standards

1060

1061 Section 6.7 of NIST SP 500-291 (Version 2) of NCCP Standards Roadmap

1062

1063 Accessibility is relevant to cloud computing services at the application level where a human 

1064 interacts with an application. This is where accessibility is measured. Therefore, many of the 

1065 existing accessibility standards for ICT applications are relevant to cloud computing applications.

1066

1067 The U.S. Access Board is an independent federal agency devoted to accessibility for people with 

1068 disabilities. The Access Board develops and maintains design criteria for the built environment, 

1069 transit vehicles, telecommunications equipment, and for electronic and information technology. 

1070 It also provides technical assistance and training on these requirements and on accessible design 

1071 and enforces accessibility standards that cover federally funded facilities.

1072

1073 Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d), requires that 

1074 Federal employees with disabilities have access to and use of information and data that are 

1075 comparable to the access and use by federal employees who are not individuals with disabilities. 

1076 Section 508 also requires that individuals with disabilities, who are members of the public 

1077 seeking information or services from a federal agency, have access to and use of information 

1078 and data that are comparable to that provided to the public who are not individuals with 

1079 disabilities. Both of these requirements must be met unless an undue burden would be imposed 

1080 on the agency.

1081

1082 Section 508 standards that would be applicable for many cloud computing applications are: 

1083 Subpart B -- Technical Standards

1084 1194.21 Software applications and operating systems; 

1085 1194.22 Web-based intranet and internet information and applications; and 

1086 1194.23 Telecommunications products.

1087

1088 The Access Board is in the process of revising the Section 508 standards. This is the first major 

1089 revision since the standards were initially published in 2001. The initial product oriented 

1090 approach to requirements is being replaced with a more functional approach. The Access Board 

plans to reference the W3C’s Web Content Accessibility Guidelines (WCAG) 2.011 1091 which is an 

1092 international voluntary consensus guideline. 

1093

1094 Additional voluntary consensus standards that may be applicable to cloud computing 

1095 applications are: 

ISO 9241-20:200812 1096 , Ergonomics of human-system interaction -- Part 20: Accessibility guidelines 

1097 for information/communication technology (ICT) equipment and services

 

11 http://www.w3.org/TR/WCAG20/

12 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40727
NIST SP 500-317 Cloud Computing Accessibility Considerations 

31

ISO 9241-171:200813 1098 , Ergonomics of human-system interaction -- Part 171: Guidance on 

1099 software accessibility; 

ANSI/HFES 200 14 1100 Human Factors Engineering of Software User Interfaces (Parts 1, 2, and 3); and 

ISO/IEC 24751-1:200815 1101 , Information technology -- Individualized adaptability and accessibility in 

1102 e-learning, education and training – Part I: Framework and reference model.

1103

1104 Section 508 is more than a technical standard. It is a community of practice and a policy 

1105 structure. For example, the Rehabilitation Act requires a biannual report to Congress on current 

1106 agency compliance. The General Services Administration convenes a group of Section 508 

1107 Coordinators from the different agencies. This structure and community are under continuing 

1108 development.

1109

The White House released a Strategic Plan for Improving Management of Section 50816 1110 of the 

1111 Rehabilitation Act, January 24, 2013. The strategic plan provides a comprehensive and 

1112 structured approach to further improve agencies’ management of the requirements of Section 

1113 508. The objective is to ensure that all electronic and information technology (EIT) that is 

1114 developed, procured, maintained, or used by the federal government is accessible, as required 

1115 by Section 508 of the Rehabilitation Act of 1973.

 

13 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=39080

14 http://www.hfes.org/Publications/ProductDetail.aspx?Id=76

15 http://www.iso.org/iso/catalogue_detail?csnumber=41521

16 https://www.whitehouse.gov/sites/default/files/omb/procurement/memo/strategic-plan-508-

compliance.pdf
NIST SP 500-317 Cloud Computing Accessibility Considerations 

32

1116 Table 4: Excerpt from NIST SP 500-291

Categorization Available Standards SDO Status

Accessibility Section 508 standards (Technical Standards 

1194.21 Software applications and operating 

systems; § 1194.22 Web-based intranet and 

internet information and applications; and 

1194.23 Telecommunications products)

US Access 

Board

Approved Standard

Market Acceptance

Under Revision

W3C Web Content Accessibility Guidelines 

(WCAG) 2.0

W3C Approved Standard

Market Acceptance

ISO 9241-20:2008, Ergonomics of humansystem interaction -- Part 20: Accessibility 

guidelines for information/communication 

technology (ICT) equipment and services

ISO/IEC Approved Standard

ISO 9241-171:2008, Ergonomics of humansystem interaction -- Part 171: Guidance on 

software accessibility

ISO/IEC Approved Standard

ISO/IEC 24751-1:2008, Information 

technology -- Individualized adaptability and 

accessibility in e-learning, education and 

training -- Part 1: Framework and reference 

model

ISO/IEC Approved Standard

ANSI/HFES 200 Human Factors Engineering of 

Software User Interfaces (Parts 1, 2, and 3)

ANSI Approved Standard

1117

1118
NIST SP 500-317 Cloud Computing Accessibility Considerations 

33

1119 Appendix D: Current Taxonomies

1120 Below, in alphabetical order, is an annotated list of accessibility taxonomies currently in use, 

1121 including those in active development. Some are implicit, in that they were not intended for use 

1122 as taxonomies, but serve as informal categorization schemes. Note: some other taxonomies 

1123 were collected, but not included in this document at this time; the list is shown in Appendix B.

1124 D1. AbleData

1125 http://abledata.com/

1126 AbleData is a database of 20,000 assistive technology devices, oriented to clinicians and 

1127 consumers with disabilities. Detailed product information is provided, including where it can be 

1128 purchased. AbleData is supported by NIDILRR in the US Department of Health and Human 

1129 Services.

1130 It has 20 top-level categories, of which the ICT-relevant ones are:

1131  Blind and Low Vision

1132  Communication

1133  Computers

1134  Controls

1135  Deaf and Hard of Hearing

1136  Deaf Blind

1137  Education

1138  Environmental Adaptations

1139  Recreation

1140  Workplace

1141 “Computers” is broken down further:

1142  Computer Accessories

1143 o Computer Accessories General

1144 o Cursor Control Accessories

1145 o Monitor Accessories

1146 o Tablet Computer Accessories

1147  Hardware

1148 o Cards

1149 o Central Processors

1150 o Disks and Tapes

1151 o Input

1152 o Modems

1153 o Output

1154  Software

1155 o Computer Access Interfaces

1156 o Computer Assisted Instruction

1157 o Computer Assisted Training
NIST SP 500-317 Cloud Computing Accessibility Considerations 

34

1158 o Evaluation

1159 o Functional Applications

1160

1161 “Computer Access Interfaces” is further broken down into “Motor Disability Access” (19 lowest1162 level categories, pointing to about 100 products) and “Sensory Disability Access” (40 categories, 

1163 pointing to about 250 products).

1164

1165 D2. Access for All

1166 http://imsglobal.org/accessibility/

1167 The IMS Global Learning Consortium houses the Access for All (AfA) project on accessible 

1168 learning materials and experiences. It is described as “promot[ing] an inclusive user experience 

1169 by enabling the matching of the characteristics of resources to the needs and preferences of 

1170 individual users.” Those needs and preferences are to be captured in a user-defined statement, 

1171 then used as the template for identifying resources that meet them. Although aimed at 

1172 educational content, the AfA specification can be used more broadly, covering both content and 

1173 interfaces in any use environment. 

1174 Currently, AfA Version 3 is in public review. Version 2 was published as ISO 24751. 

1175 The top level categories are “Display”, “Language”, “Control”, “Content”, and “Extension”. The 

1176 specification is structured as hierarchical classes with attributes. For example, the “Display” class 

1177 contains a “Text Reading Highlight” attribute, which has its own class, which contains a “Pitch” 

1178 attribute, etc.

1179

1180 Figure 2 - Screenshot of AfA Voice Recognition attribute within the Control class.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

35

1181

1182 Figure 3 - Screenshot of AfA Voice Recognition data model, showing “voice profile 

1183 identity” as one of several attributes.

1184

1185 Figure 4 - Screenshot of AfA showing details of “voice profile identity”.

1186 The Accessibility Metadata Project (http://www.a11ymetadata.org/) has licensed an AfA subset 

1187 to schema.org. Schema.org has modified and extended that subset and is actively disseminating 

1188 it to the search industry, with the goal of letting content authors tag, and users find, accessible 

1189 resources more easily.

1190
NIST SP 500-317 Cloud Computing Accessibility Considerations 

36

1191 D3. Cloud4All Semantic Framework for Content and Solutions (SEMA)

1192 The Cloud4All project (one of the contributing projects to building the GPII) developed its 

1193 Framework for developers who want to include their products and settings in GPII. They 

1194 describe it as “an ontological layer containing instances and metadata about solutions, 

1195 platforms, devices and their specific settings in a semantic hierarchical manner”. Thus it is 

1196 structured with a registry of common terms, a repository of products and solutions, rules for 

1197 matching solutions to needs, and a tool for managing the content of the framework, the 

1198 Semantic Alignment Tool (SAT). This allows solution providers such as AT vendors to enter the 

1199 characteristics of their products needed for GPII compatibility. The browser view of the SAT is 

1200 too large to usefully show here. It has 2 navigation panes and a content pane.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

37

1201

1202 Figure 5 - Screenshot of SAT navigation panes.

1203
NIST SP 500-317 Cloud Computing Accessibility Considerations 

38

1204

1205 Figure 6 - Screenshot of SAT content pane.

1206 The term “Reg_AnnounceCapitals” means that announcing capitals, a setting in a screen reader 

1207 that aids recognizing proper nouns, is a common term in the Registry. Among its Relationships 

1208 are its description (“announce uppercase letters as ‘cap x’”) and its possible setting value, true 

1209 or false (on or off). Note that 2 vendors have entered the characteristics of their products, NVDA 

1210 and SAToGo.

1211

1212 D4. EASTIN

1213 http://www.eastin.eu/en/searches/products/index

1214 EASTIN (European Assistive Technology Information Network) is an aggregation of European 

1215 national information resources on AT. It uses the ISO 9999:2011 classification schema (see 

1216 below) as its framework, so it includes non-ICT products and more or less medical devices. 

1217 EASTIN has extended ISO 9999 with terms that pertain to ICT and/or characteristics of use, such 

1218 as languages supported by the solution, or operating systems it can run on; and subdivided it for 

1219 more detail, adding such terms as “touch screens” and “speech synthesizers”. Not all of this new 

1220 classification is exposed on the public EASTIN site.

1221 The EASTIN taxonomy has 2 levels, Clusters and Features. For example, the Feature “tactile 

1222 display” is found in the “Output device” Cluster.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

39

1223 Specific product information is available via several search pathways.

1224 The full ICT-focused taxonomy can be found at 

1225 http://wiki.gpii.net/index.php/The_vocabulary_of_the_EASTIN_taxonomy

1226

1227

1228 Figure 7 - Screenshot of EASTIN search results at the Cluster level, indicating the number 

1229 of hits.

1230

1231

1232 Figure 8 - EASTIN screenshot showing some of the results for “Assistive Products for 

1233 Communication and Information ... Input devices for computers ... Input software”.

1234 D5. Global Accessibility Resource Initiative (GARI)

1235 https://www.gari.info/
NIST SP 500-317 Cloud Computing Accessibility Considerations 

40

1236 GARI is a database created and maintained by the mobile phone manufacturers (through their 

1237 trade association, Mobile Manufacturers Forum) to help consumers with disabilities find phones 

1238 they can use.

1239 It is aggregated by the FCC for its Clearinghouse (mandated by CVAA).

1240 GARI is broken down by disability category, and then by accessibility feature.

1241

1242 Figure 9 - Screenshot of GARI search portal front page.

1243
NIST SP 500-317 Cloud Computing Accessibility Considerations 

41

1244

1245 Figure 10 - Screenshot of GARI search option page.

1246

1247

1248 Figure 11 - Screenshot of GARI list of accessibility features associated with cognitive 

1249 disabilities, with definitions.

1250

1251 D6. IndieUI User Context

1252 The Independent User Interface (IndieUI) Task Force is a W3C/WAI project intended to develop 

1253 unified interface guidelines to “... make it easier for web applications to work in a wide range of 

1254 contexts — different devices, different assistive technologies (AT), different user needs” by 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

42

1255 standardizing accessibility-relevant methods for software developers. There are 2 “sides” to 

1256 IndieUI: Events and User Context; the latter is relevant here. The goal of the User Context work 

1257 is “to provide authorized web applications access to information about a user's relevant settings 

1258 and preferences....” Thus it refers to settings for text (font, color, background color), alternative 

1259 formats (captions, description), high contrast, inversion, and screen reader. IndieUI is currently 

1260 under development; the working draft of User Context is here: http://www.w3.org/TR/indie-ui1261 context/.

1262

1263 D7. ISO 9999:2011

1264 This is a standard for categorizing assistive technology, and includes some medical devices. The 

1265 ICT-relevant top-level categories are:

1266  Training in skills

1267  Communication and information

1268  Employment and vocational training

1269  Recreation

1270 ISO 9999 uses a 3-part set of 2-digit codes. The first 2 digits refer to a domain of use (e.g., ‘22’ is 

1271 ‘Communication and Information’). The second 2 digits either refine the domain of use (e.g., 

1272 ’22.21’ is ‘Face-to-Face Communication’) or refer to a disability dimension (e.g., ’22.06’ is 

1273 ‘Hearing’). The third set is a specific AT product category (e.g. ’22.36.03’ is ‘Keyboards’).

1274 The full set of subcategories for Communication and Information is:

1275  Seeing

1276  Hearing

1277  Voice production

1278  Drawing and writing

1279  Calculation

1280  Record, play, and display audio and visual information

1281  Face-to-face communication

1282  Telephoning and telematic messaging

1283  Alarming, indicating, reminding, and signaling

1284  Reading

1285  Computers and terminals

1286  Input devices for computers

1287  Output devices for computers

1288

1289 Note that ISO 9999 is used by EASTIN (above).

1290

1291 D8. Job Accommodation Network (JAN)

1292 http://askjan.org/
NIST SP 500-317 Cloud Computing Accessibility Considerations 

43

1293 The Job Accommodation Network is the US Department of Labor, Office on Disability 

1294 Employment Policy’s database of job-related accommodations, focused on commercial AT 

1295 products. It is aimed at employers trying to find individual accommodations for employees (or 

1296 applicants) with disabilities, and is also used by people with disabilities and AT practitioners.

1297 JAN’s main pathway to solutions begins with selecting from a list of disabilities, but one can also 

1298 search directly by product or service:

1299

1300 Figure 12 - JAN’s main pathway: Information by Product or Service

1301 Beneath this level are specific AT product types; here’s what’s shown under “Product listing for 

1302 Vision Impairments”: 
NIST SP 500-317 Cloud Computing Accessibility Considerations 

44

1303

1304 Figure 13 - Product listing for Vision Impairments

1305 JAN target pages for these links give a list of manufacturers and their contact information.

1306 D9. M376

1307 Mandate 376 (M376) is a statement by the European Commission about the public procurement 

1308 of accessible ICT, soon to be implemented in law. The Mandate led to a new European ICT 

1309 accessibility standard, promulgated by 3 standards bodies: ETSI, CENELEC, and CEN. M376 is 

1310 similar to Section 508, in that it is aimed at ICT in public procurement; the effort to build the 

1311 European standard is aware of the parallel, referring to Section 508 in several places.

1312 The main standards document is EN 301 549 (referred to as ‘EN’). EN begins with functional 

1313 performance statements covering vision, hearing, speech, dexterity/range, cognition, 

1314 photosensitivity, and privacy.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

45

1315 The bulk of EN is structured in Clauses that cover requirements for different technologies, 

1316 beginning with a Generic Clause for all technologies. This is followed by Clauses for 2-way voice, 

1317 video, hardware, web, non-web documents, software, documentation, and relay and emergency 

1318 services. Some Clauses are sub-divided (e.g., “Caption processing technologies” within “Video”). 

1319 At the bottom level are specific requirements. The Web Clause parallels WCAG 2.0.

1320 EN contains 2 Annexes, one of which explains the relationship between the functional 

1321 performance statements and the requirements, in table form:

1322 Table 5: Table B.2 shows the relationship between functional performance statements 

1323 and specific requirements, indicating where the relationship is primary (supports the 

1324 functional performance statement) or secondary (the feature is needed by some users, 

1325 or in some situations).

1326

1327

1328 D10. Raising the Floor

1329 http://research8.misericordia.edu/

1330 Raising the Floor is developing an accessibility taxonomy on behalf of the Consumer Electronics 

1331 Foundation, to categorize both accessibility features and consumer electronics products that 

1332 might have them. In this it is similar to GARI, and it too may eventually be populated by 

1333 manufacturers themselves, and used by consumers.

1334 The Features section is divided into functional categories that map somewhat onto human 

1335 performance (“easier to understand”, “easier to physically operate”, etc.), but moves away from 

1336 a medical model, putting the focus on the design rather than the user. The Product Types 

1337 section is driven by the intended domain, consumer electronics.

1338
NIST SP 500-317 Cloud Computing Accessibility Considerations 

46

1339

1340 Figure 14 - Screenshot of RtF taxonomy, showing both the Feature and Product 

1341 hierarchies and first sub-categories.

1342

1343

1344 Figure 15 - Screenshot of RtF taxonomy showing bottom-level feature details

1345

1346 D11. Section 508

1347 http://section508.gov

1348 In brief, Section 508 of the Rehabilitation Act requires US federal agencies to purchase 

1349 accessible ICT. Its use has spread to other parts of the public sector. It is currently under 

1350 revision, which will change its product categorization schema. Currently, it is divided into:

1351  Software Applications and Operating Systems

1352  Web-based Internet information and applications

1353  Telecommunications Products

1354  Video and Multi-media Products
NIST SP 500-317 Cloud Computing Accessibility Considerations 

47

1355  Self-Contained, Closed Products (meaning products to which accessibility accessories 

1356 cannot be attached, and onto which accessibility software cannot be installed, such as 

1357 copy machines)

1358  Desktop and Portable Computers

1359 (There are also functional performance criteria that use a typical disability categorization, and 

1360 provisions for documentation and support not relevant here.)

1361 Under each product category are provisions that cover specific accessibility issues. For example, 

1362 in the Web category one provision states that “[A] method shall be provided that permits users 

1363 to skip repetitive navigation links.”

1364 D12. Tables of Taxonomies

1365 We have raised the point that information resources can be categorized along several 

1366 dimensions, and in fact it is important to do so in order to understand how well those 

1367 dimensions (especially audiences) are covered by the resources currently in use. As an 

1368 experiment, below are some partial tables indicating how this categorization could be 

1369 developed and visualized.

1370 D12.1. By Audience

1371 ‘P’ indicates primary audience; ‘S’ indicates secondary audience.

Developers Content 

creators

PWD Practitioners Technology 

managers

Policy 

makers

AbleData P P S S

Access4All S P

Cloud4All 

SEMA P

EASTIN P P S

1372

1373 D12.2. By Dimension

1374 ‘X’ indicates that the indicated taxonomy (row) is scoped to or includes information or 

1375 categorization in the dimensions (columns).

Disability / 

performance 

category

Context 

of use

Product 

category

Technology 

feature Legal/regulatory Standard

AbleData X - X X - -

Access4All - Education X -

ISO 

24751

Cloud4All 

SEMA - - X - ISO 9999

EASTIN X - X - ISO 9999

1376

1377
NIST SP 500-317 Cloud Computing Accessibility Considerations 

48

1378 D13. Taxonomies found within technical standards; not included at this time

1379 Some taxonomies or sources of useful categorization were not included in this draft:

1380  HFES 200.2 is the accessibility portion of HFES 200, a usability standard for 

1381 computer interaction.

1382  ISO 9241, a standard for the ergonomics of human-computer interaction.

1383  Voluntary Voting System Guidelines, a product of the Election Assistance 

1384 Commission, which contains systematically specified requirements for usability 

1385 and accessibility.

1386  Web Content Accessibility Guidelines (WCAG 2.0), especially the Techniques.

1387 D13.1. ICF

1388 http://apps.who.int/classifications/icfbrowser/

1389 The UN’s World Health Organization (WHO) puts forth a classification scheme for human 

1390 functioning called the International Classification of Functioning, Disability and Health, or “ICF”. 

1391 The ICF is not explicitly technological; its relevant section categorizes human functions into 

1392 Chapters in an attempt to move from a medical model of disability to a social model, wherein an 

1393 individual’s ability to fulfill social roles via active participation is seen as the interaction between 

1394 personal characteristics (e.g., severe vision loss) and environmental factors (e.g., attitudes and 

1395 social institutions). Technology is one of the environmental factors.

1396 ICF is included here because it is a prominent taxonomy in disability studies and policy 

1397 development, and several clinical tools have been built from it. It could be used, or cross1398 referenced, in a taxonomy for accessible technology.
NIST SP 500-317 Cloud Computing Accessibility Considerations 

49

1399

1400 Figure 16 - Screenshot of ICF Browser showing Chapter structure within “Activities and 

1401 Participation”.

1402

1403 Figure 17 - Screenshot of ICF Browser showing functional detail.

1404 As an example of how ICF could be integrated into an accessible technology taxonomy, an 

1405 accessibility feature or product that addresses a functional limitation in receiving written 

1406 content would be tagged under ‘d325’.