In control of different systems, so this particular presentation is one I think that
you really are going to enjoy. If you don't know about the Playbook, Playbook was created by our
office to assist individuals as they are going through the development process and procurement
process. So, we have Miss Lynette Banning, a senior accessibility subject matter expert at
the office -- and I can't use OAST anymore -- I'm sorry, accessibility usability, uh,
group. I would say is that who's going to do her presentation? Lynette, are you available?
>> I'm here.
>> All right, there you go. Now I can see you and I can hear you. Excellent,
excellent. How are you this morning?
>> I'm doing well. We haven't had too many, too many uh problems with
the smoke yet. I guess it's headed our way, so I hope you'll still be able to hear me.
>> Yes, some people, yeah. Unfortunately, that smoke has definitely moved its way down here
where I live also. Uh, I don't know if my dog is going to want to go outside to go to the
restroom later on because of the smoke, but we'll make it through one way or another. Well, again,
this is the introduction of Lynette Banning. She's a senior accessibility subject matter expert,
again at accessibility and usability, and Lynette, I know I'll let you kind of take it from here.
>> Um, and start to present
supporting the DHS accessibility and usability program.
Today, I'll be presenting on accessibility training, as Vince said, with a focus on
continuing to bring developers into alignment with DHS accessibility best practices. I'll be covering
more technical information than you've heard so far, so please bear with me. I hope it'll be
useful though, and so I'm going to go off camera now to manage the slides and my notes. Okay?
>> Lynette, this is, uh, Vince. Can you,
um, see if you could turn your volume up a little bit or speak a little bit louder?
>> Absolutely. Thank you. A little bit better?
>> A bit better. They said increase, yeah. People are saying if you can
increase the volume or can we get your mic up a little bit?
>> Okay, uh, let me get closer to the speaker. Here, is that better?
>> That's better. I can definitely hear you now.
>> That's great, um, I wanted to first, um, mention that a lot of the material
we're going to cover today is based on original content created by Alan King,
um, a former senior accessibility engineer that worked with us. Many of you on the call may know
Alan; he was in the field for many, many years and unfortunately passed away earlier this year.
Um, very sad, of course. Um, he had left with us with, um, some very valuable suggestions
for training for developers, and I'm going to include that in what I, uh, tell you about today.
So, let me go to the agenda here. First, we're going to recap concepts from an award-winning
white paper written by Alan King and Kristen Smith O'Connor that you may have seen last year.
I'm just going to show you some highlights as it applies to the developer training.
Um, it's, uh, the white paper is on a subject called Accessibility DevOps initiative,
and we'll talk more about that in just a moment. Can you hear me now very well.
>> Yes, I think we can hear you pretty good.
>> Okay, good. Next, um, after that, we'll present currently available tools to support development
teams, meet accessibility goals, and show you the DHS section 508 Playbook that provides role-based
guidance throughout the SDLC in alignment with Accessibility DevOps recommendations.
Then, we'll introduce the goals and accessible developer training course envisioned by Alan
King that further advances Accessibility DevOps concepts specific to developers. And finally,
direct you to an existing GitHub developer support site that provides guidance on integrating section
508 into test automation, a cornerstone of the Accessibility DevOps initiative.
First, we'd like to state that today's briefing is built on an understanding that one,
federal agencies must comply with codified standards when they develop, procure, maintain,
or use information and Communications technology. Two, DHS has a standardized test methodology for
ensuring compliance that must be followed. And three, DHS has institutionalized processes to
address accessibility throughout the software development life cycle. This presentation
will guide you to tools available at DHS that align with these 508 compliance requirements.
I wanted to mention that some material being presented today is from earlier briefings
and has been modified to present a cohesive view of accessibility training for Developers
and, importantly, two, instructions to access material materials mentioned today are going
to be provided at the end of the presentation that will be available to you upon request.
>> All right, so, um, Accessibility DevOps, the next few slides present highlights from
the Accessibility DevOps -- that's a tongue twister and I say it many times -- throughout
this presentation. The white paper, written by Alan and Kristen specifically for the benefit
of engineering teams, describes the initiative, the DevOps principles on which it is founded,
and practical approaches for implementing the initiative within an organization. I just want
to mention that you'll see SDLC (software development) and software engineering used
interchangeably throughout the presentation as they were referred to in their original sources.
Okay, so, what is Accessibility DevOps? Accessibility DevOps builds on agile DevOps
principles by expanding those principles to highlight the subject matter of accessibility.
Implementing Accessibility DevOps practices improves the performance of software development
operations in three ways: by incorporating accessibility personnel into the DevOps team,
by incorporating accessibility best practices into the DevOps processes,
and by integrating automated accessibility tools into DevOps testing environments.
This slide illustrates a contrast in the timing of accessibility considerations in the development
process. The first diagram shows the Legacy approach that addresses accessibility toward
the end of the software development life cycle. The second diagram shows what Alan King refers
to as the "CALM" approach - collaboration, automation, shifting left - by incorporating
accessibility early in the development cycle and monitor monitoring outcomes,
addressing accessibility during all cycles of development from planning through acquisition
and all iterations of development to ensure issues are identified and remediated ahead of production.
Accessibility DevOps practices can enhance compliance with accessibility, security,
UI/UX design, improve speed, and reduce costs through automating manual tasks,
and resulting in better management of complex development environments.
My apologies for that oversight. Here's the transcript without the numeric list:
The white paper concluded with recommendations for implementing Accessibility DevOps practices
in your organization, and those include: Review and embrace the Section 508
Playbook that we're going to show you in a moment, the Cure stakeholder commitment,
promote a culture shift, introduce Accessibility DevOps initiative and
activities to the team and the organization, identify and include key roles in an activities,
implement training and cross-training, integrate Accessibility DevOps activities into the SDLC,
and introduce accessibility test automation and common tool sets.
Developers have specific responsibilities in learning and applying accessible code
and best practices with the end goal of creating applications with
accessible navigation and user interfaces compatible with assistive technology.
Developers also integrate accessibility testing into current unit testing and
into existing continuous integration, continuous delivery automation tools.
Several training tools available at DHS to assist development teams
include the widely available and known Trusted Tester training and certification program,
Accessibility Docks Community of Practice (we won't cover in detail today),
the DHS Section 508 Playbook (you'll hear more about in a moment), and finally,
the Accessible Developer Training Course initiated by Alan King (will also present today).
The first training vehicle, primarily geared toward testers and developers,
is Section 508 Trusted Tester Training and Certification. The Trusted Tester
process was originally created by DHS and later adopted by several other U.S. federal agencies.
The mission of The Trusted Tester program is to promote a unified, consistent, shareable,
and repeatable test and evaluation approach for Section 508 standards conformance.
The Trusted Tester training track provides a path to earn the Trusted Tester certification
for web on the Windows platform. Upon completion of the training, students will be able to identify
the Section 508 standards applicable for web and use the test process to evaluate websites
and web applications for conformance to the revised Section 508 standards. Students that
score a 90 or better on a final exam receive Trusted Tester certification.
You can find the link to register for the course on the DHS internet site, and those without
access to the site can call the accessibility help desk or write the help desk for more information
(contact information at the end of the presentation).
Okay, the DHS Section 508 Playbook is another tool created to provide role-based guidance
to IT project and acquisition team members based on accessibility best practices.
The Playbook is instrumental to implementing the Accessibility DevOps initiative,
as it contains the strategies, alignments, plays, and roles for each team member,
and the resources to successfully meet the goal of accessibility.
The Playbook is available from the Accessibility and Usability homepage on the DHS intranet,
that is only available to DHS employees. However, a generic version of The Playbook
is currently being updated and will be made available on max.gov.
We won't cover the playbook in detail today, but we wanted to represent the tool to you,
as far as it plays a major role in implementing Accessibility DevOps. We'll
also point out several organizational changes we made to enhance usability.
In alignment with the Accessibility DevOps recommendations, The Playbook
guidance is strategic to each phase of the development life cycle. You'll find
the life cycle diagrams on the Playbook site customized for each team role that provide a
high-level view of how each play aligns with the official DHS acquisition life cycle framework,
as well as the software engineering life cycle adopted by DHS. You can find more information
about the DHS life cycles and the how-to-use The Playbook presentation available on the site.
The Playbook guidance aligns with specific team roles common to most development teams: IT project
managers, acquisition teams, developers, testers, at 508 PMs, and SMEs. When you select your role,
the plays that apply to you are displayed. There are 14 possible plays and Associated activities
that may apply to your role; a specific play can actually apply to multiple team roles.
When you select your team role, you can then select from four distinct Playbook views that
each provide different types of guidance unique to the role selected. Lifecycle summary view
is a concise list of links to reference material for the recommended activities needed to address
section 508 requirements throughout the life cycle by actions. This section was added to highlight
the key deliverables associated with each play, consisting of Key activities, play outputs,
authorizations required, and available resources. We'll show this to you on the next slide.
Planning checklist view is a customizable, customizable fillable PDF checklist of
role-based activities talk more about also and training and resources containing job
aids and other role-based resources aligning to activities and a particular life cycle phase.
So, what's new? As we mentioned, we recently created a new play actions
view that highlights play outputs or deliverables,
if you will, authorizations required, and relevant resources required in each phase.
This makes all the wonderful information that was initially put on the Playbook,
put in the Playbook, um, easier to access and at your disposal. There are generally six primary
plays recommended for the developer, who may also be involved in other plays depending on
the team construct. The main activities include ensuring section 508 requirements are addressed
in planning and design and coding, as well as unit testing and Remediation.
Detailed guidance and relevant resources for each play are available on the Playbook website.
The Playbook has a planning checklist tool, as we mentioned, that generates a customizable PDF
form by team role. The forms are in a functional checklist format and have been updated to include
the new play actions to help teams ensure they meet all necessary compliance steps.
All right, in imagining course content geared toward what developers need most,
Alan King referred to the need for a different kind of training.
He describes the Legacy strategy as relying on accessibility training that teaches how to access,
assess rather, already built ICT for conformance with requirements.
That training is critical and ICT needs to be compliant. However,
Alan cites that that approach may allow for technically compliant coding constructs that you
would not necessarily encourage technical teams to replicate for usability or Enterprise use reasons.
He, therefore, proposed a new coding examples approach to development, focusing on best
practice that includes six components: UI solutions that align with WCAG standards, when
multiple code approaches meet clients' use, the approaches that represent W3C recommended syntax.
Implement accessible coding approaches that are most user-friendly per the 21st Century IDEA Act.
When multiple code approaches meet compliance, use the approaches that align with the automated
tool of choice (Site Improve, etc.). I know some of this terminology will not be familiar to many
of you, and others who may be developers, it's ringing true to them. That Site Improve is a
scanning tool for to, uh, to assess compliance conformance that's used it across DHS by many,
many organizations, many agencies. When multiple code approaches meet compliance,
use the approaches that best integrate into your organization's code base. Allen suggests
that meeting the goals of one through five lends itself to code reuse and building an
Enterprise accessible code Library, one end goal of the Accessibility DevOps initiative.
So far, we've introduced the concept of Accessibility DevOps that builds on the principles
of DevOps by incorporating accessibility subject matter, as well as stressing the importance of
incorporating accessibility throughout the SDLC, as presented in the DHS section 508 Playbook.
The next few slides will show how Alan envisioned further expanding developer
training in accordance with Accessibility DevOps team recommendations via a targeted accessible
developer training course that follows the code example approach you saw in the last slide.
The purpose of the accessible developer training for web is to teach the core
knowledge and activities needed to allow them to leverage their unique place in the
software development life cycle to maximize the likelihood of creating accessible ICT.
Summarizing the goals for the accessible developer training course,
first recognize, I-I see how small that print is, but I'll read it to you:
recognize why accessibility is important and is the responsibility of all SDLC roles;
write better code from understanding how accessibility Works under the hood (we'll
explain more later); identify which development efforts have accessibility implications and make
that identification early in the life cycle; collaboratively design coding and user interface
strategies that promote accessibility in the design and develop phases of SDLC;
recognize, create, and successfully implement accessible coding techniques; integrate manual and
automated accessibility unit testing during code development and defect remediation; and finally,
establish and maintain a collaborative dialogue with Section 508 subject matter experts to
iteratively improve accessible design, coding, and to build an accessible code library over time.
This course is intended to primarily be targeted to the SDLC role of web architecture developer
or coder, or at least part of their coding responsibility is in the design and coding of
the application's presentation or front-end layer. The training venue would be an online self-paced
training that presents its content to the learner from the viewpoint of the software developer role.
The course would assume the learner is familiar with HTML5, JavaScript, CSS,
and Aria, as well as development frameworks and programming languages being used.
Proposed course content would include web accessibility fundamentals,
accessible design, accessible coding techniques, accessibility unit testing,
accessibility remediation, and progressive elaboration, such as institutionalizing accessible
coding practices through code libraries and other practices to streamline accessible development.
First module, web accessibility fundamentals, would present a contextual backdrop to
accessibility activities that will serve as the underlying foundation on which all other
technical recommendations in the course are built. Web fundamentals would include introduction to
web accessibility and the W3C standards, why accessibility matters, accessibility
in the software development life cycle (specifically to align with DHS requirements),
how web accessibility works (getting under the hood). This content would be particularly
geared toward developers, the learning objective being how accessibility is technically achieved
through the use of HTML elements, semantics, the document object model, and the accessibility tree.
And lastly, a section on understanding the myriad of accessibility references, infusing context
and clearing confusion. Developers are often lost in a sea of Section 508 and accessibility
references. This section would describe the purpose each serves as well as how they relate
to each other. The material would include a simple roadmap for how to use the references
effectively in daily design and coding efforts to conform to the DHS accessibility standard.
Next module would be accessible design, starting with navigation and content structure. The section
describes how and why accessible design is enhanced when developers strategically apply
HTML semantic elements in the creation of an underlying organized and intuitive structure on
which user interface elements are built. WCAG conformance requirements two and three would
describe the accessibility design implications of the Section 508 performance requirement
full page, full web page performance, and complete process conformance, for example.
I know that doesn't make sense to some people, but it does to others. And finally,
how to choose user interface controls that promote accessibility, implementing HTML elements and
audio coding as they were designed to be used, and choosing HTML elements in other widgets.
We come to accessible coding techniques, the learning objective here is to teach
accessible coding techniques that will comply with the six components
mentioned in relation to the DevOps best practices presented earlier,
including the WCAG and The Trusted tester Section 508 conformance test process.
Uh, I think I want to stay here first. Next, we have accessibility unit testing, an integral part
of the Accessibility DevOps initiative. This module describes how the developer role can
strategically integrate automated and manual accessibility unit testing into the develop
phase of the life cycle using the Trusted tester for web testing methodology. This method would
also cover use of several automated testing tools such as AX Core that can be customized to Trusted
tester-friendly automated rule sets currently available on GitHub that we'll present next.
Then we have the accessibility remediation module. It would not only cover recommendations for fixing
code but in institutionalizing accessible coding techniques to iteratively reduce future errors
through activities such as tracking accessibility coding defects to conclusion and leveraging Site
Improve reports and Remediation activities. Matured course content referred to here as
progressive elaboration could include content to assist in assessing development processes
through agile ceremonies, institutionalizing accessible coding practices and code libraries,
and capturing specific coding techniques for commonly used development languages such as HTML5,
Angular, or React that also align with WCAG guidelines and DHS compliance standards.
Most all development frameworks and languages have documented accessibility guidelines,
uh, guidance rather, you can refer to in their documentation,
keeping in mind the end result needs to comply with DHS standards as well.
So, Alan King and others at AU have created a GitHub developer support area on GitHub
to provide guidance on integrating automated accessibility testing in alignment with the
Accessibility DevOps initiative. The purpose of the dev automation resource is to provide
fully functional examples to DHS components on integrating accessibility test automation. For
DHS components who don't have access to GitHub, there is a mirror site in Bitbucket. Instructions
to access the site are provided in the reference slides at the end of the presentation.
We want to emphasize the recommendations for automated testing is never meant to replace
manual testing, as only 30 percent of WCAG success criteria can be detected by automated
methods. Rather, automation is meant to be a powerful efficient tool when applied correctly.
Or this slide shows the dev automation code examples and a screenshot of the associated
code repository of test automation scripts used to integrate Section 508
into your test environment. Using the examples assumes knowledge and experience with GitHub and
knowledge of any test frameworks into which you plan to integrate any of the accessibility test
libraries presented. The tools presented in the repository represent a wide range of complexity
from relatively simple to the highly complex, from browser plugins to command-line interface tools to
API information, and for full scripting, as well as few examples AU developed that demonstrate
how some of these accessibility open-source tools can be extended to provide greater functionality.
Some of the more powerful automated tools presented allow the user to pick and
choose the individual underlying rules used for testing. When automated tools have this feature,
the user can exercise much more control over the quality and relevance of their test results.
Okay, future training and support. Today, we've shown you the principles behind the Accessibility
DevOps initiative. We've also shown you tools to assist you in implementing the recommendations
through embracing the DHS Playbook and integrating accessibility throughout all phases of the
development life cycle. The need to seek relevant developer accessibility training and guidance
on integrating test automation into the development environment.
And looking ahead to future training and support, several developers we spoke with raise the issue
that they often don't actually write HTML, that it's rendered by the framework or otherwise in
a black box. They also may not have access to change code provided by another team or even
another company working on the same project. I ran into that myself in the past, and that's worth
addressing for sure in real time. These situations need to be triaged on an individual basis due to
the variable development environments. Otherwise, when front-end code is available to modify,
utilizing best practices and coding techniques and coding in anticipation of Trusted Tester
requirements and outcomes from automated compliance reporting tools is the optimal goal.
AU will continue to explore methods to facilitate training and support for development through
continuing to explore accessible developer training, expanding Dev automation pilot
initiatives, and instituting a collaborative Message Board to share questions and solutions.
That's my favorite, as well as other trainings such as incorporating customer experience.
Alan put together a simple roadmap to implement the Accessibility DevOps initiative presented
today. He suggested developers, in particular, should acquire the following skills and training:
knowledge of WCAG as described in The Trusted tester conform test process for web,
the ability to choose compliant ICT authoring tools, the ability to implement code
strategies that meet Section 508 and usability requirements while achieving ICT business need,
and the ability to efficiently implement Section 508 unit testing in the SDLC.
To summarize, the primary training resources for development teams we covered today that align to
the Accessibility DevOps roadmap include the Trusted Tester training certification,
the DHS 508 Playbook, and the dev automation GitHub code resources and examples.
That concludes my presentation. So, if you have questions or would like to access any
of the materials presented today, please write to or call the DHS accessibility desk. There
are also reference slides at the end. A few requests: a copy of the presentation,
you'll see at the end here, there are specific references to the information mentioned today.
>> Thank you very much, there, Miss Lynette. We appreciate that presentation. It's full
of information, for sure. You do have a couple of questions. One that came in is,
do you experience Site Improve giving false flags on AA or A issues on your websites,
and if so, how do you resolve them?
>> I'm sorry, I was still manipulating my computer.
>> False negatives, yeah, that's... that's the
triage I was mentioning that needs to happen on an individual basis.
That is a very common problem, and I don't think we have the bandwidth today to address that, but
having the rule sets set up in advance and the scanning software is key to avoiding that.
>> Good. Let me see if we can get to another one here.
So, what is the best... another question came in from Ms. Juanita Thomas.
What is the best way to present or promote this training to developers? Oftentimes, they are
apprehensive to go through the training due to the time, especially for the Trusted Tester training.
>> You know, that was actually the impetus for Alan wanting to do the developer-specific course,
yep, so that it could kind of be a pick and choose by the table of content, um, and that
they wouldn't need to go through the structured path that the Trusted Tester track does.
But, um, I would have to defer to Nick on that. Um, there's, um, you know, I mean,
it goes back to literally the course content that was proposed, um, to address that issue.
>> Understood. Understood. One other person, can you please go back to the reference slides again?
Sure, I think they were trying to capture that data. Oh, there you go. And remember,
these slides will be made available later. Um, if you would like to have them, you can always
send the emails again to accessibility@hq.dhs.gov, and we will provide that information to you later.
See if there's any other questions.
So, Lynette, dealing with the developer training, are you able to tell the participants when do
we think we will have an ETA on that being created and going out to folks?
>> Yeah, I'll defer to Nick on that.
>> So, folks, basically, that's the politically correct answer: stay tuned. Uh, we are going to
be working on that, and that will be something that will come out, you know, soon. Uh,
I am actually interested. How many people on the call right now, before we go into our next
presentation, are Trusted Testers currently or have used the Playbook? And if you have,
um, can you put in the chat, or the PB, because I'm just kind of
interested in seeing. Oh, a couple people say me. Okay, here you go. Interesting.
Very good, a lot, a lot of Trusted Testers. A couple of people have used the Playbook
already. Very good, very good. Now we know that the Trusted Tester training,
um, is challenging, to say the least, uh, because, again, we're trying to make sure
that people really have a full understanding of how to test and what to look for. But now
that you have gone through the Trusted Tester training, do you feel that that
has made you more aware when it comes to identifying accessibility-related issues?
Um, and you can just put it in the chat, yes. Somebody says they want to be a Trusted Sister,
indeed. Okay, very good, very good. Very good. Now, one thing, and I'll just bring this one
last point up, we had a conversation within our office, um, the other day, and it is the fact that
a lot of people are doing Trusted Tester training, but they may not know how to report. So, the ACRT
is the report that you can utilize if you do not know how to properly use the ACRT or have access
to the ACRT, please reach out again to our office, and we will be glad to provide you that level
of support to ensure that you have a reporting mechanism for your post-Trusted Tester reports.
All right, Lynette, I don't know if there's any other questions. Oh,
there you go. Thanks. Thank you so much. Savage has put in the link for GitHub,
how to get to the ACRT for a test report. And again, if you don't know how to use this report,
uh, we definitely will provide you with that information. Uh, if you don't have any other
questions, I want to say thank you so much, Miss Banning, for this great presentation. Thank you.
It was my honor to present work that Alan King worked very hard on. Yes, he definitely did,
and you served him well in honoring him today, and you did a great job of presenting this
information. So, uh, and we will continue to keep working in his honor, uh, moving forward.
>> Thank you so much. Bye-bye.
>> Bye-bye. All right, guys, we actually are at our break,
so I like to do that, you know. I don't really do sign language, but I try to. I think I'm