[Athen] Web accessibility audit

[Sam Joehl]

An SSB formal audit<https://www.ssbbartgroup.com/reference/index.php/Formal_and_High_Level_Audit_Comparison>will
identify the violations in your system against all relevant
accessibility requirements. During a formal audit the system is tested
using a combination of automatic, manual and use case testing with the
leading assistive technologies by engineers with disabilities. The formal
audit provides independent verification and validation (IV&V) of the
application/website and obligates SSB to work with our clients to defend
any claims of compliance challenged by end customers. The written report
for a formal audit consists of a general audit report accompanied by a
series of appendices. The deliverables for a formal audit include:



*Audit* – The Audit Report is the comprehensive report detailing the
findings, violations, and compliance level of the tested application. It
includes an Executive Summary, compliance metrics with the selected
accessibility standards, product-specific examples of significant
violations, and extensive technical documentation about every type of
accessibility best practice that was violated. These examples and best
practice descriptions include generic examples of compliant and
non-compliant code, recommendations (including specific syntax), and the
specific accessibility paragraph or checkpoint it falls under.

*Appendix A* – The Modules by Total Violation document lists the module
name and the number of violations on each module.

*Appendix B* – The Modules Detail document depicts what violations are in
each module. In short, this appendix is a detail of Appendix A. The details
may include a short description, whether it is part of a violation pattern,
and the line number of the rendered HTML page source.

*Appendix C* – The Violations by Priority appendix displays the severity,
frequency, noticeability, and tractability (i.e. the typical degree of
difficulty to fix) of each discovered violation. These factors are combined
to establish a rough prioritization of the discovered violations. The
violations are ranked on a scale from 1 (lowest) to 10 (highest), which
offers a gauge of the development effort that may be required to remediate
the problems.

*Appendix D* – The Use Case Results appendix documents the use cases that
are meant to define the core functionality that is in use within the
application and the results from the testing of these use cases.
Accessibility problems that were encountered at any step of any use case
are identified, along with any relevant AT-specific settings or notes. The
results of each use case are ranked on a scale of 1 (lowest, meaning the
use case was a total failure that could not be completed) to 5 (highest,
completely successful). As with the manual testing, violation patterns are
also identified, as well as AT-specific compatibility and configuration
issues.

*Appendix E* – The Module List document lists and illustrates the modules
that are tested. This ensures that the client’s developers and testers can
cross-reference each module with the problems documented in Appendices A
and B.

*Appendix F* – The Violation Patterns table describes accessibility
problems that are found on many, most, or all modules. It is a convenient
alternative to, and a subset of, the much fuller Appendix B, which also
includes the results from automated testing and problems that are found
only on individual pages. A significant amount of analysis goes into the
identification of these Patterns, which are typically used as the primary
examples pictured and discussed in the main Audit Report.

*AMP Licenses Subscription* – SSB’s AMP User Licenses provide
“Accessibility-on-Demand” for the development teams in a self-serviced,
self-paced easy to comprehend format which drastically reduces the cost of
administering an accessibility program. AMP is a web-based platform for the
implementation and management of accessibility across enterprise-class
development organizations spanning multiple development platforms,
deployment environments, and user interface patterns.

*Voluntary Product Accessibility Template (VPAT)* – The VPAT provides the
compliance level with each Section 508 paragraph. In addition to a formal
“grade”, it also describes specific accessibility features, documentation,
and some types of accessibility problems.



We have worked with several postsecondary educational institutions as well
as purveyors of leading LMS systems to implement accessibility. If we can
be of assistance to you, don’t hesitate to contact
us<https://www.ssbbartgroup.com/contact.php>
.



Sam Joehl

SSB BART Group

Sam.joehl at ssbbartgroup.com

Accessibility-On-Demand

Follow us: Facebook <http://www.facebook.com/#!/ssbbartgroup> |
Twitter<http://twitter.com/#!/SSBBARTGroup>
 | LinkedIn <http://www.linkedin.com/company/355266?trk=tyah> |
Blog<http://www.ssbbartgroup.com/blog>
 | Newsletter <http://eepurl.com/O5DP>



A DeVry alumni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20120417/27245d87/attachment.html>