This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "Industry:DOJ Nondiscrimination on the Basis of Disability"

Jump to: navigation, search
Line 32: Line 32:
  | style="width:25%; background:#7B8ABD" align="center"| '''Deadlines'''  
  | style="width:25%; background:#7B8ABD" align="center"| '''Deadlines'''  
  | colspan="3" style="width:75%; background:#cccccc" align="left"|
  | colspan="3" style="width:75%; background:#cccccc" align="left"|
* 9 Nov 2010 - Complete first draft response
* 9 Nov 2010 - Complete second draft response
* 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
* 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
* 19 Nov 2010 - Prepare final version
* 19 Nov 2010 - Prepare final version

Revision as of 21:35, 8 November 2010

Return to Global Industry Committee

Activity Name DOJ Nondiscrimination on the Basis of Disability
Short Description Provide response to "Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations"
Related Projects None
Email Contacts & Roles Primary
Alexander Fry
Lorna Alamri
Mailing list
Please use the Industry Committee list
  • Review Proposed Rulemaking - in particular issues relating to Web application security
  • Where appropriate, draft a response for submission
  • Submit the response as an official OWASP statement
  • 9 Nov 2010 - Complete second draft response
  • 12 Nov 2010 - Circulate to OWASP chapters and GIC mailing lists
  • 19 Nov 2010 - Prepare final version
  • 22 Nov 2010 - Submit to DOJ
  • In Progress
Resources Document detail

Annotated version

Project plan

Other comments submitted

Response submission to Federal eRulemaking Web site: by 24th January 2011

Submission Response

Latest first

Final version


Draft Text version 2


Draft Text version 1

CW's notes

CW: I think the following questions posed by the DoJ are the most relevant for response by OWASP. My comments on each of those are included below.

1.) Should the Department adopt the WCAG 2.0s "Level AA Success Criteria" as it's standard for Web site accessibility for entities covered by Titles II and III of the ADA? Is there any reason why the Department should consider adopting another success criteria level of the WCAG 2.0?

From a website security point of view, WCAG 2.0s "Level AA Success Criteria" is not inconsistent with having a secure website. Conformance levels A, AA and AAA all require additional considerations for security due to the use of:
  • input, storage and output of additional text
  • alternative forms of CATCHA
  • input, storage and output of additional files
  • third party services
  • additional client-side scripting
  • flexible session timeouts
  • enforcing code validity
These can all be achieved using secure development practices, but the additional requirements increase complexity. There is one aspect in the more stringent "Level AAA Success Criteria" which would be difficult to achieve in a secure manner:
  • re-authentication recovery
Reference: "Can an accessible web application be secure? Assessment issues for security testers, developers and auditors", Colin Watson, OWASP AppSec Europe 2009,

6.) What Resources and services are available to public accommodations and public entities to make their Web sites accessible? What is the ability of covered entities to make their Web sites accessible with in-house staff? What technical assistance should the Department make available to public entities and public accommodations to assist them with complying with this rule?

The W3C WAI pages on WCAG 2.0 provide ample information. In particular the "Techniques and Failures for Web Content Accessibility Guidelines 2.0" provide excellent guidance and duplication of this effeort elsewhere would appear to be un-necessary. In terms of ensuring the security is maintained, we recommed OWASP's own guidance documents, standards and tools such as the Top Ten, Development Guide, Code Review Guide, Testing Guide, Application Securitity Versification Standard and the Software assurance Maturity Model. These are already referenced by organisations such as DISA, NIST, NSA and the FFIEC.
Reference: OWASP Citations

7.) Are there distinct or specialized features used on Web sites that render compliance with accessibility requirements difficult or impossible?

At Conformance Level AA, no.

8.) Given that most websites today provide significant amounts of services and information in a dynamic, evolving setting that would be difficult, if not impossible, to replicate through alternative, accessible means, to what extent can accessible alternatives still be provided? Might viable accessible alternatives still exist for simple, non-dynamic Web sites?

It is important that alternative means provide the same level of protection to the users, their data and the business systems, so that for example weaker authentication requirements in an alternative telephone service make it easier to steal a person's identity than through an online website service, or the telephone service can be used to assist exploitation of the website (e.g. enumerate usernames).

19.) The Department is interested in gathering other information or data relating to the Department’s objective to provide requirements for Web accessibility under titles II and III of the ADA. Are there additional issues or information not addressed by the Department’s questions that are important for the Department to Consider?

In the OWASP response to Question 1, we stated that an accessible website can be secure. It is also worth mentioning that an insecure website possibly may not be accessible because it would be possible to create web pages (responses) which are do not met the conformance requirements. A simple example would be injecting code which includes inaccessible content from a third party website, or which breaks the code validity because an extra H1 tag has been inserted.

Some customised About OWASP text

This response is submitted on behalf of the Open Web Application Security Project (OWASP) by the OWASP Global Industry Committee. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a U.S. recognized 501(c)(3) not-for-profit charitable organization, that ensures the ongoing availability and support for our work at OWASP.

OWASP has previously submitted responses to related standards and guidance:

  • BS 8878:2009 Web accessibility. Building accessible experiences for disabled people DPC
  • W3C Mobile Web Application Best Practices Working Draft

and NIST documents such as NIST SP 800-37 (Rev 1), SP 800-53 (Rev 3), SP 800-122 and IR 7628.

Return to Global Industry Committee