Michael Gower was in charge of the 2016 accessibility checklist that IBM released for software and web last year, in preparation for the final release of 508 Refresh. He is also heavily involved in IBM’s current work to roll out a new unified checklist in response to the final Rule.
Could folks whoop, beep or show their hands, just so I get a feel for who is in the audience. Advanced Notice of Propose Rule Making
Photo by WillMcC - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4379199
Three broad phases: Review refresh (Digesting the Final) Compare Final to Existing guidance, produce new guidance.
Focus on IBM’s experience
Tactical approaches for adoption: Scope and Harmonization, VPAT 2.0, Identifying Holes and seeking clarification
Referernces will be to the “Refresh” consistently in this presentation.
-Not spending too much time addressing a lot of Final specifics
-depending on the state on an Enterprise’s current accessibility guidance and what its business focus is, entirely different thing might be relevant.
-general take aways that are relevant to everyone.
- Open link. I’ve included the link to the access board final rule on this slide, but just do a search for “Section 508 Refresh Final Rule”
Overview of the rule link on right-hand column under ICT Refresh heading
Less than 2000 words.
Less than 8 full screens of text at normal magnification.
Compared to over 21,0000 for the single-page version of the Standard and the
55,000 for the impact analysis
ICT – Information and Telecommunication Technology
Links under Table of Contents on left side of page
508 applies to “all types of public-facing content, as well as nine categories of non-public-facing content that communicate agency official business, have to be accessible,”
Final Impact analysis is bigger than standard itself.
9. Major New Requirements in the Final Rule
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-regulatory-impact-analysis#_Toc471376838
Federal Overview with anchors
Federal register version offers a means to create anchors on any paragraph in the body text. Only mouse-based. Also contrast issues.
The impact analysis also has anchors built in.
Scoping includes Legacy ICT exception, undue burden, alternative means,
Now that we’ve contectualized the final rule, we need to ask what we’re comparing it to…
Show of hands for current guidance
EN 301 549, which is the European accessibility
For web content, it’s difficult to imagine anyone working exclusively from 20 year old guidance. Meeting final should be easy, but lessons to take away from IBM’s interim analysis process
Photo: By WillMcC - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4379199
Detail from Impact Analysis, Table A-1. WCAG 2.0…
NOTE: The 508 Corresponding Reference uses web 1194.22 , software 1194.21 and Video and multimedia 1194.24
It helps to have mappings going both ways, both WCAG to 508 Legacy, as here, and 508 Legacy to WCAG.
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-regulatory-impact-analysis#_Toc471376905
I’ll go into some detail about the legacy 508 criteria we retained in our interim checklists
I’m just including the information on the software checklist here to show that we had a parallel process for non-web software. I’ll discuss that material later in detail.
Look at three phases of IBM mapping and analysis, from 3 checklists
First page shows the blend approach IBM took historically for Legacy, 2008. Simply a mapping exercise.
Second page maps back to 5.2. It adds in the impact analysis column as well as comments/guidance. Largely a renumbering exercise. Includes legacy not covered by WCAG
Bring up XL file of latest round. Only examining the difference between draft and final, but also pulling in harmonization with EU considerations.
IBM ‘made up’ a new WCAG number that corresponds to a WCAG Conformance requirement.
We created some headaches for ourselves having to retain 508 Legacy – happy to leave behind
However, matching apples and oranges still a consideration when we get to software because of overlap between WCAG and the 502 Interoperability requirements.
If there is a failure in WCAG, can’t report 508 success, even though it may be fine.
http://www-03.ibm.com/able/guidelines/ci162/web61to52.html#legacy-508-web
These checkpoints represent 508 requirements that are not covered by WCAG techniques. Teams can arguably dismiss testing for them; however, I would contend that there are considerations for 1194.22(d) – the requirement to be readable without style sheets – that could be maintained
http://www-03.ibm.com/able/guidelines/ci162/web61to52.html#non-wcag
Look at the Overview.
FPC: “These criteria apply only where a technical requirement is silent regarding one or more functions or when evaluation of an alternatative design or technology is needed under equivalent facilitation.”
https://www.federalregister.gov/d/2017-00395/p-122
FPC: “These criteria apply only where a technical requirement is silent regarding one or more functions or when evaluation of an alternatative design or technology is needed under equivalent facilitation.”
Points from David Capozzi’s EU presentation:
Basis for equivalent facilitation and used to determine whether substantially equivalent or greater accessibility is provided
When ICT features do not conform to technical requirements, test those features against the functional performance requirements
IBM has used equivalent facilitation to meet the legacy 508 requirement 1194.22 (d) readable without requiring style sheets.
Table A-5. Final Rule Provisions Benefitting People With Specific Types of Disabilities
Table A-5 identifies specific provisions in the final rule that would benefit people with the following specific types of disabilities:
Blind: Person with significant vision impairment who prefers to use a non-visual interface.
LV (Low Vision): Person with significant vision impairment, but who prefers to use a visual interface when available.
Deaf: Person who prefers to use a non-auditory interface.
HoH (Hard of Hearing): Person with a significant hearing impairment, but who prefers to use an auditory interface when available.
Motor: Person with limited manual dexterity, reach range (including someone using a wheelchair), or strength.
Speech: Person limited on their ability to speak clearly.
CLL (Cognitive, Language, and Learning): Person with limited ability to process, understand, or comprehend information.
Photo (Photosensitivity): Person who is susceptible to visually induced seizures.
Need a clarification written by the U.S. Access Board. The way this was written, if you don't meet all of the WCAG criteria you've got to complete the other software requirements - even if your application doesn't have access to platform services. This can't technically be accomplished and filling out the Software requirements for such a web application doesn't make sense.
Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.
“EXCEPTION: Authoring tools shall not be required to conform to 504.2 when used to directly edit plain text source code.
The image shows how the github editor enforces heading structure if a user attempts to change the text size.
Two basic tactics – either treat Documentation as a separate deliverable and complete a full VPAT for it; or, incorporate documentation into the application itself and test those features as part of the web app
Impact analysis. Covers Interoperability, Applications and Authoring Tools
https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-regulatory-impact-analysis#_Toc471376906
https://www.federalregister.gov/d/2017-00395/p-430
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance.
I’ll go into some detail about the legacy 508 criteria we retained in our interim checklists
Note the July 2016 dates “New (current practice)” in the Final Impact Analysis. Very similar to the Table A-1 in the Access Board Impact Analysis, but does not include legacy 508 web.
1:1 Straightforward; not always perfect language match but clear
1:2 Two criteria in WCAG clearly link to a single 508 checkpoint
1:Many Broadness of items means many new checkpoints apply
In our interim, we elected to retain existing 508 checkpoints with new numbering
Also had 7 legacy
Lots of overlap between WCAG and Interoperability requirements.
Mention July 2016 stamps, to support phased approach
Interim measures to retain old reporting (2nd link)
So, what are our tactics this time? Estimated dates.
Federal Acquisition Regulatory Council update July 18, 2017 (update within 6 months) Assumption: That FAR Council will not be late.
Give teams 6 months
Adoption timeline for procurement. Requirement as soon as FAR Council updates rule. Companies can say ‘you are supposed to be using the new rules’. Ability to make complaint in process of bidding. Jan 20, 2018 date by which agencies are required to comply.
Supposed to start using language in procurement processes as of July.
Safe harbor only applies to agency, not the third party.
The Word doc has macros for:
- hiding and showing sections
When multiple standards are being recorded in this document, the duplicative sections are noted and responded to only one time. The duplicate entry will note the cross reference to the data.
I couldn’t make the macros work
Seeking clarify
- We will also likely have to split each of the lettered items into a checkpoint so we can map individual requirements between the EN and 508.
- May have to add separate requirement to “identify” templates
