Upload
raina-austin
View
220
Download
1
Tags:
Embed Size (px)
Citation preview
End the Madness - Section 508 Compliance in the Enterprise
About SSB BART Group
• Experience• Accessibility Focus• Solutions That Manage
Risk• Real World Fixes• Excellence at Scale• Knowledge That Is Up-
to-Date, All the Time
About SSB BART Group
• Fourteen hundred organizations (1452)
• Fifteen hundred individual accessibility best practices (1512)
• Twenty-three core technology platforms (23)
• Twenty-two thousand audits (22,408)
• One hundred twenty-one thousand human validated accessibility violations (121,290)
• Fifteen million accessibility violations (15,331,444)
Timothy Stephen Springer
• Founder of SSB Technologies, CEO SSB BART Group
• Fourteen years of experience in web accessibility
• Eighteen years of experience in web development consulting
• Consulted with hundreds organizations on web accessibility policies and practices
• Principal architect of InFocus, AMP and DCQL
• BS CS Stanford, AI focus• Two month old child (second, boy) at
home – slept well for the first time last night
Agenda
• Current Reality• Accessibility Initiative Phases
– Policy– Standards– Procurement and Contracting– Testing Plan– Training– Pilot Project
• Accessibility Program Office• Appendices
– Roles and Responsibilities– Implementation Plan
Current Reality
• People with disabilities face profound access challenges
• 18.7% of population has a disability
• 12.6% has a severe disability• Rates drastically increase with
age• In working age population
– 41.1% employment rate (all disabilities)
– 27.5% employment rate (severe disabilities)
Inaccessible ICT is a Huge Barrier
Current Reality
• 508 promised a huge impact on accessible ICT– Progress was made but more
remains• ADA and related legislation likely to
have a far greater impact• Our goals remain the same
– Drastically increase employment of people with disabilities
– Ensure participation in society for people with disabilities
– Fulfill the civil rights of people with disabilities
The Promise of 508
Accessibility Initiatives Phases
• Policy – Overall approach and structure• Standards – Nuts and bolts• Procurement and Contracting – Buy accessible stuff• Testing Plan - How do we validate accessibility?• Training – Who gets trained on what?• Pilot Project – Do one, learn stuff
Enterprise Accessibility PolicyRound One
• Technical Standards – 508 v. WCAG• Scope – What’s covered?• Timeline – When to conform? (Hint: Now)• Priority – What first? (Anathema! Heretic!)• Exceptions – What and how?
– Statutory - Undue Burden, Substantial or Fundamental Alteration
– Operational - Other User Provided and Generated Content, Linked Sites and Resources, External Content, Live Content, Short Term Content, Orphan Content, Low Traffic Content, Third Party Applications
• Functional Support – Level of equivalent access
Enterprise Accessibility PolicyRound Two
• Non-complianceWhat happens if we don’t comply? (Often nothing…)
• Supported ATWhat assistive technologies do we support?
• Vendors How do we address this with vendors?
Monitoring PlanAccessibility Initiatives
Metrics and Measurements
• Overall compliance score• New development
compliance score• Upgraded system
compliance score• Production system
compliance score
Issues
• Monitor inbound IT Accessibility issues
• Reporting time frame• Number of incidences • Work to resolve issues• Time to resolve issues • Are we meeting out policy
targets?
Other Key Policy Docs
Accessibility Statement • Organization wide accessibility statement
– Publish it everywhere– Required under OMB Strategic Plan, AODA
Accessibility Issue Resolution Policy • How do we resolve issue relating to accessibility?• Ideally like we resolve other issues
Technical Standards
Cover core technology platforms, generally:• Web• Flash• Multimedia• PDF• Word• Excel• PowerPoint• iOS• Android• Other platforms (desktop,
hardware) as needed
• Technical Standards• Implementation Guide
– 100 – 200 best practices– For each provide
• Description of issue• User impact• Code
– Compliant Examples– Non-compliant Examples
• Recommendations• Unit Tests• Prioritization Factors
• Decision Matrix• Compliance Checklist
Procurement and Contracting
Ideal• Make it my vendor’s
problem! (Awesome!)
Reality• Your vendors have no idea
how to do this!• Without oversight you will
get inaccessible things• VALIDATE VENDOR
ACCESSIBILITY CLAIMS
Approach• Stick core compliance
language into all IT contracts • Require vendors to submit
accessibility testing records• Have service vendors submit
testing results per organization’s testing plan
• Accessibility testing generates lots of records
• No records = no accessibility testing
Example Compliance Language
[CLIENT] expects that all vendors providing information technology products or services will provide [CLIENT] with deliverables that conform to the WCAG 2.0 AA requirements. [CLIENT] expects vendors to be able to define and deliver statements of compliance produced in accordance to a judicious, unbiased testing process as part of the procurement of the system. Statements of compliance must identify the overall compliance of the deliverable, as well as compliance of the system against each of the relevant WCAG provisions. To determine compliance with each of the provisions, a percentage can be calculated by dividing the number of tested items which do not contain violations of the guideline by the total number of items tested.
In addition [CLIENT] requires all vendors to be able to provide detailed testing records relating accessibility testing that has been performed on the system. These records must be submitted to the Accessibility Program Office for review as part of procurement and ongoing project conformance.
Example Compliance LanguageGive it teeth
VENDOR NOTES THAT FAILURE TO PROVIDE ACCURATE ACCESSIBILITY STATEMENTS WILL BE DEEMED A MATERIAL BREACH OF THIS CONTRACT AND WILL CAUSE FORFEITURE AND REFUND OF ALL SUMS PAID UNDER THE CONTRACT BY [CLIENT].
ANY BREACH OF THE ACCESSIBILITY CLAIMS MADE IN THIS CONTRACT OR FAILURE BY VENDOR TO PROVIDE ACCURATE CLAIMS IN A TIMELY FASHION WILL BE DEEMED CAUSE FOR [CLIENT] TO WITHOLD ANY OUTSTANDING PAYMENTS.
Or something that has a financial impact.
Accessibility Testing PlanAhh! So much text on this slide!
• How do we test internal stuff?
• How do we test vendor stuff?– VALIDATE VENDORS
CLAIMS• Different technology
platforms– Same testing approach– Different best practices
• Different use level – different testing approach– High use systems =
Detailed testing– Low use systems = Limited
testing• Central v. Distributed
Testing– Central testing = strong
governance, high expense– Distributed testing = weak
governance, lower costs
Accessibility Testing PlanValidation Requirements
Technical Requirements (§1194.21 | §1194.22)• Did we code it right?• Testing coverage
– Automatic (25%)– Manual (48%)– Global (27%)
• Automatic testing is cheap and commonly used but covers only a small fraction of legal requirements
Functional Requirements (§1194.31)• Can it be used by people with disabilities?
Support Requirements (§1194.41)• Is the whole thing accessible?
Accessibility Testing PlanCore Testing Methodology
Testing
ManualAutomated Global
Assistive Technology
IdentifyModules
IdentifyUse Cases
Groundwork
Prioritization
Analysis
Authoring
Delivery
Reporting
• At SSB we use a Unified Audit Methodology• One process for testing all technology platforms• Process should allow for different testing formality• Must be repeatable and scalable• Must provide concise remediation guidance• Require vendors to provide testing artifacts from the process
Accessibility Testing PlanTricky Parts
Manual Testing• Manual tests require
extensive subject matter expertise
• Manual tests are expensive• Formal audits are more
expensive
Functional Testing• Different versions of
assistive technologies, drastically different results
• Accurate testing results requires intimate knowledge of AT support and control
Accessibility Testing PlanTesting Responsibilities
General Approach
• General teams are responsible for small, targeted sub-set of requirements
• Accessibility Program Office is responsible for – Full scope testing– High risk system and component
testing• APO supported by third party
experts• Over time organization learns
more about accessibility organically versus in one disruptive and expensive push
Approach Considerations
• Accessibility program office must be developed and staffed
• For internal experts to be active they need to only be doing accessibility
• Approach requires a large amount of education and knowledge transfer for internal experts which takes a large amount of time
• Organizations may find it more effective to outsource some or all of the functions of the program office
Accessibility Testing PlanTesting Responsibilities
Team Accessibility Testing• Develop short list of core
accessibility issues for teams to test set at 90% coverage point– ~15 items
• Quick list is validated every sprint or development cycle on limited set of pages– Page test set is traffic
ordered pages and high risk transaction paths
– Test most common pages first
– Basic smoke test• Test full list every major release
Automatic Testing• Early and often• Automatic tests integrated into
functional testing system and build environment
• Addresses many low hanging fruit
• Gold standard of accessibility validation every check-in
• Good enough standard is validation of accessibility as part of regression functional test script execution
• As manual testing identifies automatically testable cases add to test definition for future automatic regression
Accessibility Testing PlanTesting Responsibilities
Functional Testing• Limit functional testing to end
cycle user acceptance testing– Note: If a product falls
under CVAA requirements user testing must occur throughout the development process
• Link limited functional testing to full review of products or systems
• Provide functional testing via users with disabilities
Training PlanRequirements
• Lots of technical standards• Accessibility issues have a
power law distribution• Small set of issue types cause
vast majority of issues • Issues recur across (a)
development teams and (b) industries
• Focus on “optimal compliance”
• Mix it up over time
Power Law Distribution
Violation NumberV
iola
tion
Cou
nt
Training PlanApproach
Target high value best practices• High severity• High frequency• High noticeability• Low tractability
Change it over time based • Monitoring data• Litigation• Legislation• Technology support• AT support
WebFlashPDFJavaWindowsHardware
Section 508WCAGDDAeEuropeNFB
LawsuitsLegislationTechnology
Organization Standard Training Content
Compliance Specification
Training PlanTraining Course Matrix
Role
Accessibility Concepts
Web Accessibility Overview
Web Accessibility Basics
Web Accessibility Advanced
Accessibility for Program and Project Management
Accessibility Testing Methodologies
Mobile Accessibility for iOS
Mobile Accessibility for Android
Product Management Product Manager x x x Business Discovery x x Concept Definition x x x Risk Management x x x x x x
Program and Project Management Project Management x x x Program Management x x x Roadmap Management x x x Portfolio Operations and Reporting x x x
Design Design x x x x x xCustomer Experience x x x x x x
Development Front-end Development x x x x x xArchitecture / Back-end Development x x x x x x
Quality Assurance Quality Assurance x x x x x xUser Acceptance Testing x x x
Documentation Document Specialists x x x
Support Support Representative x x
Pilot ImplementationAccessibility Initiatives
• Try it on a site or application• Look to see what the issues are• Learn what policies are working• Update things accordingly• Accessibility is a process – not a project
What is an APO?
Responsible for accessibility
Core Activities• Policy Ownership
– Development, Updates, Communication
• Technical Help Desk• Accessibility Testing• Measurement and Tracking• Reporting• Coordination
• Policy Updates• Policy Communication• Compliance Reporting• Exception Review• Plan Review• Technology Monitoring• General QA Support• Regulatory Monitoring• Regulatory Help Desk• Regulatory Reporting• Process Improvement
Management
Where does APO sit?• Must have a specific place for accessibility in the org
structure• Often in compliance or user experience• We see: (i) compliance, (ii) product or project management
or (iii) user experience / design
Management Sponsor• Somebody in management has to own accessibility• Signs up for accessibility metrics• Receives the report of the APO
Accessibility Council
An interdepartmental team relating to accessibility that represents the various stakeholder areas of the organization that will be impacted by accessibility.
• Facilitates progress on accessibility organization wide• Identifies issues or challenges • Works to address same• Solicits management in various different areas• Strong potential to diffuse responsibility
Next Steps
• Schedule some time to speak with an SSB expert in your industry
• Sign-up for a webinar covering further topics on Web Accessibility
• Take one of our online courses covering core Web Accessibility knowledge
• Sign-up for an online AMP training sessions
• Contact the industry expert to setup a free trial of AMP
Point of Contact
Tim Springer
(415) 624-2705 (o)
Appendix A
Roles and Responsibilities
Product or Project Manager Roles and Responsibilities
• Assess business needs for accessibility based on market needs and risks
• Understand the scope of efforts required to implement compliance and include appropriate time and costs in investment plans
• Define accessibility investments• Manage vendor accessibility with Procurement and
Contracting• Develop corrective actions or programs for projects, products
and procured items that are non-compliant
DesignerRoles and Responsibilities
• Review and training on accessible design requirements• If a library of reusable UI components is maintained, ensure
the library components are accessible• Include consideration of accessibility needs in design
deliverables • Creation of accessible wireframes, palettes and templates• Coordinate with Accessibility Program Office to validate
design assets account for accessibility
DeveloperRoles and Responsibilities
• Implement user facing components in conformance with organization's Accessibility Standards
• Complete training and certification on accessibility requirements
• Review reports created by Quality Assurance or Accessibility Program Office and take action to fix open issues
• Coordinate with Quality Assurance and Accessibility Program Office to perform regression and unit testing on systems
• Consult with Accessibility Program Office on implementation ideas and approaches
• Build in accessibility unit tests
Quality Assurance SpecialistRoles and Responsibilities
• Perform limited accessibility testing on systems. • Coordinate with Accessibility Program Office on testing high-
risk system. • Review and be familiar with Accessibility testing checklist for
each platform• Perform regression testing on fixed items
Content CreatorsRoles and Responsibilities
• Access to a limited set of requirements for content. • Ability to be trained and certified on sub-set of accessibility
requirements.
Content EditorsRoles and Responsibilities
• Access to a full set of requirements relevant to the content. • Ability to be trained and certified on sub-set of accessibility
requirements. • Accessible documentation creation specialists.
DocumentationRoles and Responsibilities
• Coordinate with Accessibility Program Office to complete testing on accessibility of documentation.
• For each product or services that is covered develop an Accessibility Features document defining the accessibility features of that document.
• Ensure new documentation is developed in a fashion that conforms to the Accessibility Policy.
SupportRoles and Responsibilities
• Coordinate with Accessibility Program Office to complete testing on accessibility of support systems and process.
• Ensure new Support systems conform to the Accessibility Policy. – Coordinate with Procurement and Accessibility Program Office
on purchases, products and services. – Coordinate with Development and Accessibility Program Office
on internally developed systems.
Human ResourcesRoles and Responsibilities
• As needed, engaged the human resources department or team responsible for the employee facing policy on accessible ICT.
• Employees - Who is the point of contact for IT accessibility issues relating to employees? For example, the company intranet is non-compliant and a worker with a visual impairment cannot access information about the company.
• Job Seekers - Who is the point of contact for IT accessibility issues relating to job seekers? For example, the online application system of job descriptions are inaccessible.
Appendix B
Implementation Plan
Implementation PlanActivities
• Define the timeline, milestones, activities and staff required to implement the overall accessibility plan.
• Provide a detailed schedule that defines the individual activities of the work effort and any dependency of groupings amongst activities. For each activity, the plan will identify duration, location, participants, roles and responsibilities, milestones and dependencies amongst activities;
• Define staffing requirements and job descriptions for any additional full or partial staff required to successfully implement the plan;
• Define cost estimates for any investments required to implement the plan;
• Define a risk plan outlining potential projects risks and risk mitigation strategies; and
• Define a communication plan outlining the standard communication protocols, e-mail distribution lists and communication escrow polices for the project.
Implementation PlanActivities
• Allow for changes in the scope of activities at the direction of organization with a focus on ensuring high-risk sites are addressed with appropriate alacrity.
• Use scenario modeling to explore a variety of different scenarios for addressing accessibility across time and various different sites provided at organization. – (i) various different approaches to the
accessibility roll out – (ii) quantify the cost-to-benefit tradeoff
between the approaches. • Scenario modeling will provide
organization with a quantitative model for determining which roll out ensures best value for the institution while providing support for an increasing level of accessibility
• The various different activities will be prioritized using a risk and prioritization model specific to organization. This model will define (i) what priority should be given to addressing individual portions of the site and (ii) what priority should be assigned to addressing individual accessibility violations. The prioritization model for individual pages, courses and site portions will generally be based on the core use cases for systems and the traffic for individual pages.
Appendix C
Reference Procurement Language
Reference Documents
• Government Product/Service Accessibility Template for GPS Navigation Device– GPS-Navigation-Device-GPAT-1.doc
• Solicitation Language for GPS Navigation Device– GPS-Navigation-Device-language-2.doc