Section 508 Refresh WCAG 2.0 A and AA Information & Comparison CB Averitt – Deque Systems
Section 508 Timeline Began in 2006 February 18, 2015: The Access Board released the proposed rule to update Section 508 Standards and 255 guidelines. The proposed rule is currently available for public comment. February 27, 2015: The proposed rule will be published in the Federal Register. March 5, 2015: The Board will hold a public hearing on the rule in San Diego. March 11, 2015: The Board will hold a public hearing on the rule in Washington, DC. March 31, 2015: The Board will conduct a public webinar to review the proposal. May 28, 2015: The deadline for submitting public comment on the proposed rule to the Access Board. After May 28, 2015: The Board will publish their final rule in the Federal Register sometime after they have received and reviewed public comment on the proposed rule. 6 Months After the Final Rule: The effective date for the ICT refresh will be 6 months after the final rule is published in the Federal Register. However, the Board is also seeking comment on the effective date, so it is possible that the 6-month window will change. We should expect finalization no earlier Q4 of 2015
Section 508 Refresh Will mirror WCAG 2.0 A and AA
Notable Push for global harmonization of accessibility standards – WCAG 2.0 standards Human testing and Verification – not just automated ( % accurate) Applies to web content, web applications, software, documents Addresses new technology
4 Main Principles of Refresh (POUR) Perceivable – Information cannot be invisible to all of a user's senses Operable – An interface must not require a user to perform tasks that they are not able to perform. No matter the tools they use to access the site, they must have a way to use it. Understandable – User interfaces and content must not be beyond the understanding and predictability of the users Robust – As technology and user agents evolve, the content should remain accessible. Don't lock into a specific thing.
WCAG 2.0 A and AA There are 38 Level A and AA Success Criteria Technology Neutral Requirements are Objectively Testable
38 Level A and AA WCAG Success Criteria Quick Review
Section 508 Refresh / WCAG 2.0 Comparison 22 of the 38 are phrased differently but are equivalent to current 508 requirements 16 success criteria are new
16 New Success Criteria & Summary Meaningful Sequence [A] – Provides for a reasonable and logical reading order when using assistive technology Sensory Characteristics [A] – Provides that instructions are not conveyed only through sound, shape, size, or visual orientation Audio Control [A] – Provides that there is a way to stop, pause, mute, or adjust volume with audio that plays automatically Contrast (Minimum) [AA] – Provides for specified contrast between foreground and background of text and images of text
16 New Success Criteria & Summary Resize Text [AA] – Provides for content that remains readable and functional when the font size is doubled No Keyboard Trap [A] – Provides that the keyboard focus is not trapped when the keyboard is used for navigation Focus Order [A] – Provides for a keyboard oriented navigation order that is reasonable and logical. Provides that links, form elements, and other user interface controls and components have a reasonable and logical navigation order Link Purpose (In Context) [A] – Provides that the purpose of any link is understandable for its text or context
16 New Success Criteria & Summary Multiple Ways [AA] – Provides for two or more means to locate content Headings and Labels [AA] – Provides that headings and labels are descriptive Language of Page [A] – Provides that the default language of content is exposed to assistive technology Language of Parts [AA] – Provides that changes in language are exposed to assistive technology
16 New Success Criteria & Summary Consistent Navigation [AA] – Provides that repeated navigational components occur in the same relative order each time they are encountered Error Suggestion [AA] – Provides that the system makes suggestions for correction when input errors are automatically detected and suggestions are available Error Prevention (Legal, Financial Data) [AA] – Provides that when legal, financial, or test data can be changed or deleted the changes or deletions can be reversed, verified, or confirmed Parsing [A] – Provides that significant HTML/XHTML validation and parsing errors in source code are avoided
Questions? Contact Information CB Averitt – –