Section 508 Refresh: Understanding the New Requirements Tim Springer CEO, SSB BART Group

Section 508 Basics

Section 508 Overview Requires Electronic and Information Technology (EIT) developed, purchased, used, and maintained by the Federal government to be accessible to people with disabilities The United States Access Board issues the standards Required for all US Federal government ICT –Adopted as a best practice for procurement by most US public sector organizations –Often required for state programs using Federal funds (Section 504)

Section 508 Covered Technology “Includes information technology and any equipment or interconnected system or subsystem of equipment, that is used in the creation, conversion, or duplication of data or information. The term electronic and information technology includes, but is not limited to: Telecommunications products (such as telephones), Information kiosks and transaction machines, World Wide Web sites, Multimedia, and Office equipment such as copiers and fax machines.” Quoted from § Definitions of the Section 508 regulations

Regulatory Status

Section 508 Refresh Timing NPRM published in Federal Register February 27 th, day comment period completed May 28 th, 2015 –135 comments received on NPRM (Regulations.gov) –Initial regulations had around 100 comments –384 written comments on 2010 ANPRM –91 written comments on 2011 ANPRM –Two ANPRMs looked like a good Access Board strategy Comments will need to be addressed and incorporated into the final rule Rule approved by OMB Rule approved by Board

Section 508 Refresh Once final rule is published, application generally trails Significant rules effective 60 days after publication in FR Complaints can be filled under 508 rules six months after rules take effect Conformance may vary - no central enforcement or policing Each federal department/agency must revise their procurement policies and directives Matches 6 month complaint window and gives you an “effective date” of six months after publication in the FR Timing Limitations - Application

Section 508 Refresh Projected Calendar MilestonePeriodDate NPRM draft to OIRA for economic impact assessmentDONE3/31/2014 OIRA completes NPRM reviewDONE6/29/2014 OIRA review notes incorporated into draft NPRMDONE2/17/2015 NPRM published in Federal RegisterDONE2/27/2015 NPRM comment periodDONE5/28/2015 NPRM incorporation of comments365 Days5/27/2016 OIRA completes final regulation review90 Days8/25/2016 OIRA review notes incorporated into draft NPRM15 Days9/9/2016 Rule approved by BoardVaries9/12/2015 Final rule published in Federal Register5 Days9/17/2015 Rule effective date60 Days11/16/2015 Complaints allowed under new rules182 Days3/17/2016 FAR and procurement policy updates due182 Days3/17/2016

The Refresh

General Themes Use consensus based standards when possible (WCAG 2.0, PDF/UA) –Normalize to WCAG 2.0 as base standard for web, electronic content and software –Harmonize with other international standards and regulations Focus on functional use profile v. product type Define coverage for electronic content Clarify scope of functional performance criteria Define AT interoperability requirements Define requirements of authoring tools Generally bring the standard up-to-date with the modern era

Standards Structure Overall –Scoping requirements –Functional performance criteria –Technical requirements –Technical requirements organized around types of technology versus product types Requirements of all relevant technology apply –For example, a mobile phone contains hardware, software and content all in one product –Overlap of product requirements a point of much confusion in the current standards –Validate a system based on all relevant technical requirements Clarify the set of standards that will apply to a system

Harmonization and Standards Focus on voluntary international consensus standards for core technical requirements –Idea – Bigger accessibility market = better, more accessible solutions –Idea – One global accessibility standard Harmonize with other web and electronic content standards (Australia, New Zealand, Canada, Japan, Germany, France) Harmonize with international standards such as the European Union’s EN standard for public procurement of ICT EN Ten referenced standards Only really need to care about the Web Content Accessibility Guidelines (WCAG) 2.0 –A and AA success criteria –Conformance requirements PDF/UA-1 can be used for PDF docs

Functional Performance Requirements Functional performance requirements only apply in situations where: –A technology standard/guideline does not exist to address the situation –As an equivalent manner to meet the standards when a technique standard cannot be met Theoretically a safe harbor for products that are technically compliant but not usable by people with disabilities –Practically unlikely to be the case In practice should make things much easier to validate Remaining functional performance criteria tweaked for clarity No cognitive requirement

Electronic Documents Arguably covered under the current standards but interpretations vary All public facing content covered Internal “official agency business” covered Content is broadly defined – includes agency websites, blog posts, social media sites, s and the like Official content posted on non- agency URL seems to be covered

Electronic Documents Official business content includes the following: –An emergency notification; –An initial or final decision adjudicating an administrative claim or proceeding; –An internal or external program or policy announcement; –A notice of benefits, program eligibility, employment opportunity, or personnel action; –A formal acknowledgement or receipt; –A questionnaire or survey; –A template or form; or –Educational or training materials. Narrow archival exception – can’t be publicly available

Electronic Documents Technical Standards WCAG 2.0 A and AA PDF/UA-1 as a backup Authoring tools also covered A system that can generate covered content needs to support the generation of accessible content

Interoperability Requirements ICT must be interoperable or compatible with documented features of assistive technology and accessibility features Applies to software –Not applicable to web apps – WCAG 2.0 safe harbor –Would apply to mobile apps –Would apply to mobile hybrid apps Application tricky General focus: use operating system APIs and standard system accessibility functions when available –Avoid re-implementing the drop down – use the OS native dropdown Use the SELECT element not some funky div thing you created Avoid creating editable keyboard focusable DIV elements use TEXTAREA instead

Documentation and Support Product supporting documentation - notably product documentation - must now clearly conform to WCAG 2.0 A & AA requirements Provide alternative formats for individuals that are blind or low vision on request Provide overview of accessibility features

Other Notes Real-time Text (RTT) support required for two-way synchronous text communication

Applying WCAG What does conformance mean Conform to the A and AA success criteria Conform to the WCAG Conformance RequirementsWCAG Conformance Requirements –Allows alternative versions of content can be used to meet the standards –Define an objective way to determine whether techniques meet the WCAG success criteria –Require systems be usable by assistive technology in a given environment to conform

Let’s jump in!! Core Document: –WCAG 2.0 Layers of Guidance –Walkthrough Guidelines and Success Criteria Understanding: WCAG20/ WCAG20/ –Why does this guideline or success criteria say what it does? Techniques: –Sufficient techniques - Reliable ways to meet the success criteria. –Advisory techniques – Suggestions for improving accessibility –Failures – Known failures of the success criteria –General v. technology specific techniques WCAG 2.0

Questions?

Thank You Contact Tim Springer linkedin.com/company/ SSB-BART-Group facebook.com/ SSBBARTGroup SSBBARTGroup.com/blog

About SSB BART Group Unmatched Experience Focus on Accessibility Solutions That Manage Risk Real-World Strategy Organizational Strength and Continuity Dynamic, Forward-Thinking Intelligence Fourteen hundred organizations (1445) Fifteen hundred individual accessibility best practices (1595) Twenty-two core technology platforms (22) Fifty-five thousand audits (55,930) One hundred fifty million accessibility violations (152,351,725) Three hundred sixty-six thousand human validated accessibility violations (366,096)