WEBVTT

00:00:00.120 --> 00:00:06.240
In control of different systems, so this 
particular presentation is one I think that  

00:00:06.240 --> 00:00:10.920
you really are going to enjoy. If you don't know 
about the Playbook, Playbook was created by our  

00:00:10.920 --> 00:00:16.320
office to assist individuals as they are going 
through the development process and procurement  

00:00:16.320 --> 00:00:24.540
process. So, we have Miss Lynette Banning, a 
senior accessibility subject matter expert at  

00:00:24.540 --> 00:00:31.380
the office -- and I can't use OAST anymore 
-- I'm sorry, accessibility usability, uh,  

00:00:31.380 --> 00:00:36.000
group. I would say is that who's going to do 
her presentation? Lynette, are you available?

00:00:38.240 --> 00:00:40.080
>> I'm here.

00:00:40.080 --> 00:00:46.560
>> All right, there you go. Now I can 
see you and I can hear you. Excellent,  

00:00:46.560 --> 00:00:47.820
excellent. How are you this morning?

00:00:47.820 --> 00:00:52.860
>> I'm doing well. We haven't had 
too many, too many uh problems with  

00:00:52.860 --> 00:00:58.140
the smoke yet. I guess it's headed our way, 
so I hope you'll still be able to hear me.

00:00:58.140 --> 00:01:05.940
>> Yes, some people, yeah. Unfortunately, that 
smoke has definitely moved its way down here  

00:01:05.940 --> 00:01:10.260
where I live also. Uh, I don't know if my dog 
is going to want to go outside to go to the  

00:01:10.260 --> 00:01:16.140
restroom later on because of the smoke, but we'll 
make it through one way or another. Well, again,  

00:01:16.140 --> 00:01:21.840
this is the introduction of Lynette Banning. She's 
a senior accessibility subject matter expert,  

00:01:21.840 --> 00:01:27.840
again at accessibility and usability, and Lynette, 
I know I'll let you kind of take it from here.

00:01:27.840 --> 00:01:30.660
>> Um, and start to present  

00:01:36.180 --> 00:01:39.960
supporting the DHS accessibility 
and usability program.  

00:01:40.800 --> 00:01:46.440
Today, I'll be presenting on accessibility 
training, as Vince said, with a focus on  

00:01:46.440 --> 00:01:53.580
continuing to bring developers into alignment with 
DHS accessibility best practices. I'll be covering  

00:01:53.580 --> 00:01:58.860
more technical information than you've heard 
so far, so please bear with me. I hope it'll be  

00:01:58.860 --> 00:02:05.340
useful though, and so I'm going to go off camera 
now to manage the slides and my notes. Okay?

00:02:05.340 --> 00:02:07.980
>> Lynette, this is, uh, Vince. Can you,  

00:02:07.980 --> 00:02:11.580
um, see if you could turn your volume up 
a little bit or speak a little bit louder?

00:02:11.580 --> 00:02:16.100
>> Absolutely. Thank you. A little bit better?

00:02:16.100 --> 00:02:22.440
>> A bit better. They said increase, 
yeah. People are saying if you can  

00:02:22.440 --> 00:02:25.320
increase the volume or can we 
get your mic up a little bit?

00:02:29.360 --> 00:02:35.220
>> Okay, uh, let me get closer to 
the speaker. Here, is that better?

00:02:35.220 --> 00:02:37.920
>> That's better. I can definitely hear you now.

00:02:37.920 --> 00:02:44.460
>> That's great, um, I wanted to first, 
um, mention that a lot of the material  

00:02:44.460 --> 00:02:49.980
we're going to cover today is based on 
original content created by Alan King,  

00:02:50.880 --> 00:02:57.120
um, a former senior accessibility engineer that 
worked with us. Many of you on the call may know  

00:02:57.120 --> 00:03:02.640
Alan; he was in the field for many, many years 
and unfortunately passed away earlier this year.  

00:03:04.140 --> 00:03:12.480
Um, very sad, of course. Um, he had left with 
us with, um, some very valuable suggestions  

00:03:12.480 --> 00:03:18.060
for training for developers, and I'm going to 
include that in what I, uh, tell you about today.  

00:03:19.260 --> 00:03:26.340
So, let me go to the agenda here. First, we're 
going to recap concepts from an award-winning  

00:03:26.340 --> 00:03:32.040
white paper written by Alan King and Kristen 
Smith O'Connor that you may have seen last year.  

00:03:32.040 --> 00:03:37.440
I'm just going to show you some highlights 
as it applies to the developer training.  

00:03:39.060 --> 00:03:45.720
Um, it's, uh, the white paper is on a subject 
called Accessibility DevOps initiative,  

00:03:45.720 --> 00:03:51.380
and we'll talk more about that in just 
a moment. Can you hear me now very well.

00:03:51.380 --> 00:03:55.560
>> Yes, I think we can hear you pretty good.

00:03:55.560 --> 00:04:02.220
>> Okay, good. Next, um, after that, we'll present 
currently available tools to support development  

00:04:02.220 --> 00:04:10.740
teams, meet accessibility goals, and show you the 
DHS section 508 Playbook that provides role-based  

00:04:10.740 --> 00:04:15.240
guidance throughout the SDLC in alignment 
with Accessibility DevOps recommendations.  

00:04:16.200 --> 00:04:21.060
Then, we'll introduce the goals and accessible 
developer training course envisioned by Alan  

00:04:21.060 --> 00:04:27.900
King that further advances Accessibility DevOps 
concepts specific to developers. And finally,  

00:04:27.900 --> 00:04:33.900
direct you to an existing GitHub developer support 
site that provides guidance on integrating section  

00:04:33.900 --> 00:04:39.540
508 into test automation, a cornerstone 
of the Accessibility DevOps initiative.

00:04:44.040 --> 00:04:49.380
First, we'd like to state that today's 
briefing is built on an understanding that one,  

00:04:49.380 --> 00:04:54.600
federal agencies must comply with codified 
standards when they develop, procure, maintain,  

00:04:54.600 --> 00:05:01.980
or use information and Communications technology. 
Two, DHS has a standardized test methodology for  

00:05:01.980 --> 00:05:08.640
ensuring compliance that must be followed. And 
three, DHS has institutionalized processes to  

00:05:08.640 --> 00:05:14.100
address accessibility throughout the software 
development life cycle. This presentation  

00:05:14.100 --> 00:05:19.800
will guide you to tools available at DHS that 
align with these 508 compliance requirements.  

00:05:20.640 --> 00:05:24.780
I wanted to mention that some material being 
presented today is from earlier briefings  

00:05:24.780 --> 00:05:29.700
and has been modified to present a cohesive 
view of accessibility training for Developers  

00:05:30.420 --> 00:05:36.720
and, importantly, two, instructions to access 
material materials mentioned today are going  

00:05:36.720 --> 00:05:40.920
to be provided at the end of the presentation 
that will be available to you upon request.

00:05:42.860 --> 00:05:50.520
>> All right, so, um, Accessibility DevOps, 
the next few slides present highlights from  

00:05:50.520 --> 00:05:56.460
the Accessibility DevOps -- that's a tongue 
twister and I say it many times -- throughout  

00:05:56.460 --> 00:06:01.440
this presentation. The white paper, written by 
Alan and Kristen specifically for the benefit  

00:06:01.440 --> 00:06:07.980
of engineering teams, describes the initiative, 
the DevOps principles on which it is founded,  

00:06:07.980 --> 00:06:14.760
and practical approaches for implementing the 
initiative within an organization. I just want  

00:06:14.760 --> 00:06:20.040
to mention that you'll see SDLC (software 
development) and software engineering used  

00:06:20.040 --> 00:06:25.080
interchangeably throughout the presentation as 
they were referred to in their original sources.

00:06:27.240 --> 00:06:35.940
Okay, so, what is Accessibility DevOps? 
Accessibility DevOps builds on agile DevOps  

00:06:35.940 --> 00:06:40.560
principles by expanding those principles to 
highlight the subject matter of accessibility.  

00:06:41.520 --> 00:06:47.160
Implementing Accessibility DevOps practices 
improves the performance of software development  

00:06:47.160 --> 00:06:53.640
operations in three ways: by incorporating 
accessibility personnel into the DevOps team,  

00:06:54.600 --> 00:06:59.460
by incorporating accessibility best 
practices into the DevOps processes,  

00:06:59.460 --> 00:07:05.280
and by integrating automated accessibility 
tools into DevOps testing environments.

00:07:08.460 --> 00:07:13.980
This slide illustrates a contrast in the timing 
of accessibility considerations in the development  

00:07:13.980 --> 00:07:20.040
process. The first diagram shows the Legacy 
approach that addresses accessibility toward  

00:07:20.040 --> 00:07:25.980
the end of the software development life cycle. 
The second diagram shows what Alan King refers  

00:07:25.980 --> 00:07:33.720
to as the "CALM" approach - collaboration, 
automation, shifting left - by incorporating  

00:07:33.720 --> 00:07:38.820
accessibility early in the development 
cycle and monitor monitoring outcomes,  

00:07:39.600 --> 00:07:44.400
addressing accessibility during all cycles of 
development from planning through acquisition  

00:07:44.400 --> 00:07:50.160
and all iterations of development to ensure issues 
are identified and remediated ahead of production.  

00:07:51.180 --> 00:07:56.400
Accessibility DevOps practices can enhance 
compliance with accessibility, security,  

00:07:56.400 --> 00:08:03.480
UI/UX design, improve speed, and reduce 
costs through automating manual tasks,  

00:08:03.480 --> 00:08:07.380
and resulting in better management 
of complex development environments.

00:08:07.380 --> 00:08:09.720
My apologies for that oversight. Here's 
the transcript without the numeric list:

00:08:09.720 --> 00:08:15.000
The white paper concluded with recommendations 
for implementing Accessibility DevOps practices  

00:08:15.000 --> 00:08:20.400
in your organization, and those include: 
Review and embrace the Section 508  

00:08:20.400 --> 00:08:25.020
Playbook that we're going to show you in 
a moment, the Cure stakeholder commitment,  

00:08:25.980 --> 00:08:31.860
promote a culture shift, introduce 
Accessibility DevOps initiative and  

00:08:31.860 --> 00:08:37.860
activities to the team and the organization, 
identify and include key roles in an activities,  

00:08:39.120 --> 00:08:45.600
implement training and cross-training, integrate 
Accessibility DevOps activities into the SDLC,  

00:08:45.600 --> 00:08:50.280
and introduce accessibility test 
automation and common tool sets.

00:08:51.660 --> 00:08:56.400
Developers have specific responsibilities 
in learning and applying accessible code  

00:08:56.400 --> 00:09:00.540
and best practices with the end 
goal of creating applications with  

00:09:00.540 --> 00:09:05.280
accessible navigation and user interfaces 
compatible with assistive technology.  

00:09:05.880 --> 00:09:10.620
Developers also integrate accessibility 
testing into current unit testing and  

00:09:10.620 --> 00:09:15.660
into existing continuous integration, 
continuous delivery automation tools.

00:09:18.360 --> 00:09:22.320
Several training tools available 
at DHS to assist development teams  

00:09:24.360 --> 00:09:30.780
include the widely available and known Trusted 
Tester training and certification program,  

00:09:32.280 --> 00:09:36.420
Accessibility Docks Community of Practice 
(we won't cover in detail today),  

00:09:37.500 --> 00:09:43.440
the DHS Section 508 Playbook (you'll hear 
more about in a moment), and finally,  

00:09:43.440 --> 00:09:49.380
the Accessible Developer Training Course 
initiated by Alan King (will also present today).

00:09:51.360 --> 00:09:55.620
The first training vehicle, primarily 
geared toward testers and developers,  

00:09:55.620 --> 00:10:01.680
is Section 508 Trusted Tester Training 
and Certification. The Trusted Tester  

00:10:01.680 --> 00:10:07.620
process was originally created by DHS and later 
adopted by several other U.S. federal agencies.  

00:10:08.280 --> 00:10:13.380
The mission of The Trusted Tester program is 
to promote a unified, consistent, shareable,  

00:10:13.380 --> 00:10:18.600
and repeatable test and evaluation approach 
for Section 508 standards conformance.

00:10:19.380 --> 00:10:24.120
The Trusted Tester training track provides a 
path to earn the Trusted Tester certification  

00:10:24.120 --> 00:10:30.540
for web on the Windows platform. Upon completion 
of the training, students will be able to identify  

00:10:30.540 --> 00:10:37.920
the Section 508 standards applicable for web 
and use the test process to evaluate websites  

00:10:37.920 --> 00:10:44.460
and web applications for conformance to the 
revised Section 508 standards. Students that  

00:10:44.460 --> 00:10:49.200
score a 90 or better on a final exam 
receive Trusted Tester certification.

00:10:49.980 --> 00:10:54.780
You can find the link to register for the course 
on the DHS internet site, and those without  

00:10:54.780 --> 00:11:00.360
access to the site can call the accessibility help 
desk or write the help desk for more information  

00:11:04.020 --> 00:11:06.120
(contact information at the 
end of the presentation).

00:11:08.700 --> 00:11:15.780
Okay, the DHS Section 508 Playbook is another 
tool created to provide role-based guidance  

00:11:16.620 --> 00:11:21.420
to IT project and acquisition team members 
based on accessibility best practices.  

00:11:22.200 --> 00:11:26.340
The Playbook is instrumental to implementing 
the Accessibility DevOps initiative,  

00:11:26.340 --> 00:11:31.740
as it contains the strategies, alignments, 
plays, and roles for each team member,  

00:11:31.740 --> 00:11:35.160
and the resources to successfully 
meet the goal of accessibility.

00:11:36.240 --> 00:11:41.340
The Playbook is available from the Accessibility 
and Usability homepage on the DHS intranet,  

00:11:41.340 --> 00:11:46.260
that is only available to DHS employees. 
However, a generic version of The Playbook  

00:11:46.260 --> 00:11:50.040
is currently being updated and 
will be made available on max.gov.  

00:11:51.420 --> 00:11:57.360
We won't cover the playbook in detail today, 
but we wanted to represent the tool to you,  

00:11:57.360 --> 00:12:02.640
as far as it plays a major role in 
implementing Accessibility DevOps. We'll  

00:12:02.640 --> 00:12:06.600
also point out several organizational 
changes we made to enhance usability.

00:12:08.820 --> 00:12:13.080
In alignment with the Accessibility 
DevOps recommendations, The Playbook  

00:12:13.080 --> 00:12:18.120
guidance is strategic to each phase of 
the development life cycle. You'll find  

00:12:18.120 --> 00:12:24.180
the life cycle diagrams on the Playbook site 
customized for each team role that provide a  

00:12:24.180 --> 00:12:30.420
high-level view of how each play aligns with the 
official DHS acquisition life cycle framework,  

00:12:30.420 --> 00:12:36.120
as well as the software engineering life cycle 
adopted by DHS. You can find more information  

00:12:36.120 --> 00:12:41.760
about the DHS life cycles and the how-to-use 
The Playbook presentation available on the site.

00:12:43.920 --> 00:12:50.280
The Playbook guidance aligns with specific team 
roles common to most development teams: IT project  

00:12:50.280 --> 00:12:58.200
managers, acquisition teams, developers, testers, 
at 508 PMs, and SMEs. When you select your role,  

00:12:58.200 --> 00:13:04.680
the plays that apply to you are displayed. There 
are 14 possible plays and Associated activities  

00:13:04.680 --> 00:13:10.380
that may apply to your role; a specific play 
can actually apply to multiple team roles.

00:13:12.420 --> 00:13:17.640
When you select your team role, you can then 
select from four distinct Playbook views that  

00:13:17.640 --> 00:13:23.580
each provide different types of guidance unique 
to the role selected. Lifecycle summary view  

00:13:23.580 --> 00:13:29.640
is a concise list of links to reference material 
for the recommended activities needed to address  

00:13:29.640 --> 00:13:36.480
section 508 requirements throughout the life cycle 
by actions. This section was added to highlight  

00:13:36.480 --> 00:13:42.420
the key deliverables associated with each play, 
consisting of Key activities, play outputs,  

00:13:42.420 --> 00:13:47.220
authorizations required, and available resources. 
We'll show this to you on the next slide.  

00:13:48.060 --> 00:13:54.180
Planning checklist view is a customizable, 
customizable fillable PDF checklist of  

00:13:54.180 --> 00:14:00.360
role-based activities talk more about also 
and training and resources containing job  

00:14:00.360 --> 00:14:05.820
aids and other role-based resources aligning to 
activities and a particular life cycle phase.

00:14:07.980 --> 00:14:13.020
So, what's new? As we mentioned, we 
recently created a new play actions  

00:14:13.800 --> 00:14:17.520
view that highlights play outputs or deliverables,  

00:14:17.520 --> 00:14:23.100
if you will, authorizations required, and 
relevant resources required in each phase.

00:14:25.380 --> 00:14:30.960
This makes all the wonderful information 
that was initially put on the Playbook,  

00:14:30.960 --> 00:14:40.260
put in the Playbook, um, easier to access and at 
your disposal. There are generally six primary  

00:14:40.260 --> 00:14:45.480
plays recommended for the developer, who may 
also be involved in other plays depending on  

00:14:45.480 --> 00:14:51.540
the team construct. The main activities include 
ensuring section 508 requirements are addressed  

00:14:51.540 --> 00:14:56.100
in planning and design and coding, as 
well as unit testing and Remediation.  

00:14:56.880 --> 00:15:01.920
Detailed guidance and relevant resources for 
each play are available on the Playbook website.  

00:15:03.480 --> 00:15:10.500
The Playbook has a planning checklist tool, as 
we mentioned, that generates a customizable PDF  

00:15:10.500 --> 00:15:17.160
form by team role. The forms are in a functional 
checklist format and have been updated to include  

00:15:17.160 --> 00:15:22.500
the new play actions to help teams ensure 
they meet all necessary compliance steps.

00:15:26.400 --> 00:15:32.640
All right, in imagining course content 
geared toward what developers need most,  

00:15:33.360 --> 00:15:37.620
Alan King referred to the need 
for a different kind of training.  

00:15:38.400 --> 00:15:44.580
He describes the Legacy strategy as relying on 
accessibility training that teaches how to access,  

00:15:45.480 --> 00:15:50.160
assess rather, already built ICT 
for conformance with requirements.  

00:15:50.880 --> 00:15:55.440
That training is critical and ICT 
needs to be compliant. However,  

00:15:55.440 --> 00:16:00.960
Alan cites that that approach may allow for 
technically compliant coding constructs that you  

00:16:00.960 --> 00:16:07.200
would not necessarily encourage technical teams to 
replicate for usability or Enterprise use reasons.  

00:16:08.220 --> 00:16:15.360
He, therefore, proposed a new coding examples 
approach to development, focusing on best  

00:16:15.360 --> 00:16:23.580
practice that includes six components: UI 
solutions that align with WCAG standards, when  

00:16:23.580 --> 00:16:30.120
multiple code approaches meet clients' use, the 
approaches that represent W3C recommended syntax.  

00:16:31.260 --> 00:16:37.560
Implement accessible coding approaches that are 
most user-friendly per the 21st Century IDEA Act.  

00:16:38.640 --> 00:16:43.740
When multiple code approaches meet compliance, 
use the approaches that align with the automated  

00:16:43.740 --> 00:16:50.640
tool of choice (Site Improve, etc.). I know some 
of this terminology will not be familiar to many  

00:16:50.640 --> 00:17:00.600
of you, and others who may be developers, it's 
ringing true to them. That Site Improve is a  

00:17:00.600 --> 00:17:10.560
scanning tool for to, uh, to assess compliance 
conformance that's used it across DHS by many,  

00:17:10.560 --> 00:17:15.960
many organizations, many agencies. When 
multiple code approaches meet compliance,  

00:17:15.960 --> 00:17:21.960
use the approaches that best integrate into 
your organization's code base. Allen suggests  

00:17:21.960 --> 00:17:28.560
that meeting the goals of one through five 
lends itself to code reuse and building an  

00:17:28.560 --> 00:17:33.480
Enterprise accessible code Library, one end 
goal of the Accessibility DevOps initiative.

00:17:36.180 --> 00:17:41.340
So far, we've introduced the concept of 
Accessibility DevOps that builds on the principles  

00:17:41.340 --> 00:17:47.400
of DevOps by incorporating accessibility subject 
matter, as well as stressing the importance of  

00:17:47.400 --> 00:17:52.800
incorporating accessibility throughout the SDLC, 
as presented in the DHS section 508 Playbook.  

00:17:53.640 --> 00:17:57.960
The next few slides will show how Alan 
envisioned further expanding developer  

00:17:57.960 --> 00:18:03.480
training in accordance with Accessibility DevOps 
team recommendations via a targeted accessible  

00:18:03.480 --> 00:18:08.280
developer training course that follows the code 
example approach you saw in the last slide.  

00:18:09.060 --> 00:18:13.440
The purpose of the accessible developer 
training for web is to teach the core  

00:18:13.440 --> 00:18:18.360
knowledge and activities needed to allow 
them to leverage their unique place in the  

00:18:18.360 --> 00:18:23.520
software development life cycle to maximize 
the likelihood of creating accessible ICT.

00:18:26.460 --> 00:18:29.880
Summarizing the goals for the 
accessible developer training course,  

00:18:31.140 --> 00:18:35.580
first recognize, I-I see how small 
that print is, but I'll read it to you:  

00:18:35.580 --> 00:18:41.880
recognize why accessibility is important 
and is the responsibility of all SDLC roles;  

00:18:43.140 --> 00:18:48.360
write better code from understanding how 
accessibility Works under the hood (we'll  

00:18:48.360 --> 00:18:54.780
explain more later); identify which development 
efforts have accessibility implications and make  

00:18:54.780 --> 00:19:02.400
that identification early in the life cycle; 
collaboratively design coding and user interface  

00:19:02.400 --> 00:19:06.960
strategies that promote accessibility in 
the design and develop phases of SDLC;  

00:19:08.100 --> 00:19:15.780
recognize, create, and successfully implement 
accessible coding techniques; integrate manual and  

00:19:15.780 --> 00:19:22.380
automated accessibility unit testing during code 
development and defect remediation; and finally,  

00:19:22.380 --> 00:19:28.200
establish and maintain a collaborative dialogue 
with Section 508 subject matter experts to  

00:19:28.200 --> 00:19:34.560
iteratively improve accessible design, coding, 
and to build an accessible code library over time.

00:19:40.080 --> 00:19:48.240
This course is intended to primarily be targeted 
to the SDLC role of web architecture developer  

00:19:48.240 --> 00:19:53.520
or coder, or at least part of their coding 
responsibility is in the design and coding of  

00:19:53.520 --> 00:19:59.940
the application's presentation or front-end layer. 
The training venue would be an online self-paced  

00:19:59.940 --> 00:20:05.580
training that presents its content to the learner 
from the viewpoint of the software developer role.  

00:20:05.580 --> 00:20:10.380
The course would assume the learner is 
familiar with HTML5, JavaScript, CSS,  

00:20:10.380 --> 00:20:14.820
and Aria, as well as development frameworks 
and programming languages being used.  

00:20:15.840 --> 00:20:19.620
Proposed course content would include 
web accessibility fundamentals,  

00:20:21.240 --> 00:20:26.520
accessible design, accessible coding 
techniques, accessibility unit testing,  

00:20:26.520 --> 00:20:34.140
accessibility remediation, and progressive 
elaboration, such as institutionalizing accessible  

00:20:34.140 --> 00:20:39.660
coding practices through code libraries and other 
practices to streamline accessible development.

00:20:42.900 --> 00:20:48.180
First module, web accessibility fundamentals, 
would present a contextual backdrop to  

00:20:48.180 --> 00:20:52.860
accessibility activities that will serve as 
the underlying foundation on which all other  

00:20:52.860 --> 00:20:59.280
technical recommendations in the course are built. 
Web fundamentals would include introduction to  

00:20:59.280 --> 00:21:06.180
web accessibility and the W3C standards, 
why accessibility matters, accessibility  

00:21:06.180 --> 00:21:11.340
in the software development life cycle 
(specifically to align with DHS requirements),  

00:21:12.540 --> 00:21:17.580
how web accessibility works (getting under 
the hood). This content would be particularly  

00:21:17.580 --> 00:21:24.000
geared toward developers, the learning objective 
being how accessibility is technically achieved  

00:21:24.000 --> 00:21:30.480
through the use of HTML elements, semantics, the 
document object model, and the accessibility tree.  

00:21:31.440 --> 00:21:38.400
And lastly, a section on understanding the myriad 
of accessibility references, infusing context  

00:21:38.400 --> 00:21:44.460
and clearing confusion. Developers are often 
lost in a sea of Section 508 and accessibility  

00:21:44.460 --> 00:21:49.680
references. This section would describe the 
purpose each serves as well as how they relate  

00:21:49.680 --> 00:21:54.300
to each other. The material would include a 
simple roadmap for how to use the references  

00:21:54.300 --> 00:22:00.480
effectively in daily design and coding efforts 
to conform to the DHS accessibility standard.

00:22:02.760 --> 00:22:08.820
Next module would be accessible design, starting 
with navigation and content structure. The section  

00:22:08.820 --> 00:22:15.240
describes how and why accessible design is 
enhanced when developers strategically apply  

00:22:15.240 --> 00:22:21.540
HTML semantic elements in the creation of an 
underlying organized and intuitive structure on  

00:22:21.540 --> 00:22:27.840
which user interface elements are built. WCAG 
conformance requirements two and three would  

00:22:27.840 --> 00:22:32.760
describe the accessibility design implications 
of the Section 508 performance requirement  

00:22:33.300 --> 00:22:39.180
full page, full web page performance, and 
complete process conformance, for example.  

00:22:39.840 --> 00:22:45.120
I know that doesn't make sense to some 
people, but it does to others. And finally,  

00:22:45.120 --> 00:22:51.240
how to choose user interface controls that promote 
accessibility, implementing HTML elements and  

00:22:51.240 --> 00:22:57.000
audio coding as they were designed to be used, 
and choosing HTML elements in other widgets.

00:22:58.980 --> 00:23:03.420
We come to accessible coding techniques, 
the learning objective here is to teach  

00:23:03.420 --> 00:23:07.380
accessible coding techniques that 
will comply with the six components  

00:23:07.380 --> 00:23:12.000
mentioned in relation to the DevOps 
best practices presented earlier,  

00:23:12.000 --> 00:23:17.100
including the WCAG and The Trusted tester 
Section 508 conformance test process.

00:23:20.760 --> 00:23:29.520
Uh, I think I want to stay here first. Next, we 
have accessibility unit testing, an integral part  

00:23:29.520 --> 00:23:36.000
of the Accessibility DevOps initiative. This 
module describes how the developer role can  

00:23:36.000 --> 00:23:41.160
strategically integrate automated and manual 
accessibility unit testing into the develop  

00:23:41.160 --> 00:23:47.460
phase of the life cycle using the Trusted tester 
for web testing methodology. This method would  

00:23:47.460 --> 00:23:54.060
also cover use of several automated testing tools 
such as AX Core that can be customized to Trusted  

00:23:54.060 --> 00:23:59.400
tester-friendly automated rule sets currently 
available on GitHub that we'll present next.

00:24:03.480 --> 00:24:09.120
Then we have the accessibility remediation module. 
It would not only cover recommendations for fixing  

00:24:09.120 --> 00:24:16.500
code but in institutionalizing accessible coding 
techniques to iteratively reduce future errors  

00:24:16.500 --> 00:24:22.860
through activities such as tracking accessibility 
coding defects to conclusion and leveraging Site  

00:24:22.860 --> 00:24:29.760
Improve reports and Remediation activities. 
Matured course content referred to here as  

00:24:29.760 --> 00:24:36.120
progressive elaboration could include content 
to assist in assessing development processes  

00:24:36.120 --> 00:24:41.880
through agile ceremonies, institutionalizing 
accessible coding practices and code libraries,  

00:24:41.880 --> 00:24:48.240
and capturing specific coding techniques for 
commonly used development languages such as HTML5,  

00:24:48.240 --> 00:24:54.480
Angular, or React that also align with WCAG 
guidelines and DHS compliance standards.  

00:24:55.440 --> 00:24:59.760
Most all development frameworks and languages 
have documented accessibility guidelines,  

00:25:00.780 --> 00:25:05.220
uh, guidance rather, you can 
refer to in their documentation,  

00:25:05.220 --> 00:25:10.260
keeping in mind the end result needs 
to comply with DHS standards as well.

00:25:13.620 --> 00:25:19.620
So, Alan King and others at AU have created 
a GitHub developer support area on GitHub  

00:25:19.620 --> 00:25:25.560
to provide guidance on integrating automated 
accessibility testing in alignment with the  

00:25:25.560 --> 00:25:30.840
Accessibility DevOps initiative. The purpose 
of the dev automation resource is to provide  

00:25:30.840 --> 00:25:38.040
fully functional examples to DHS components on 
integrating accessibility test automation. For  

00:25:38.040 --> 00:25:43.560
DHS components who don't have access to GitHub, 
there is a mirror site in Bitbucket. Instructions  

00:25:43.560 --> 00:25:47.280
to access the site are provided in the 
reference slides at the end of the presentation.  

00:25:48.300 --> 00:25:52.980
We want to emphasize the recommendations for 
automated testing is never meant to replace  

00:25:52.980 --> 00:25:58.860
manual testing, as only 30 percent of WCAG 
success criteria can be detected by automated  

00:25:58.860 --> 00:26:03.900
methods. Rather, automation is meant to be a 
powerful efficient tool when applied correctly.

00:26:05.940 --> 00:26:12.180
Or this slide shows the dev automation code 
examples and a screenshot of the associated  

00:26:12.180 --> 00:26:17.880
code repository of test automation 
scripts used to integrate Section 508  

00:26:18.600 --> 00:26:24.420
into your test environment. Using the examples 
assumes knowledge and experience with GitHub and  

00:26:24.420 --> 00:26:29.760
knowledge of any test frameworks into which you 
plan to integrate any of the accessibility test  

00:26:29.760 --> 00:26:38.400
libraries presented. The tools presented in the 
repository represent a wide range of complexity  

00:26:38.400 --> 00:26:45.780
from relatively simple to the highly complex, from 
browser plugins to command-line interface tools to  

00:26:45.780 --> 00:26:51.780
API information, and for full scripting, as well 
as few examples AU developed that demonstrate  

00:26:51.780 --> 00:26:57.000
how some of these accessibility open-source tools 
can be extended to provide greater functionality.  

00:26:57.960 --> 00:27:02.280
Some of the more powerful automated tools 
presented allow the user to pick and  

00:27:02.280 --> 00:27:07.920
choose the individual underlying rules used for 
testing. When automated tools have this feature,  

00:27:07.920 --> 00:27:13.260
the user can exercise much more control over 
the quality and relevance of their test results.

00:27:16.740 --> 00:27:21.780
Okay, future training and support. Today, we've 
shown you the principles behind the Accessibility  

00:27:21.780 --> 00:27:27.000
DevOps initiative. We've also shown you tools to 
assist you in implementing the recommendations  

00:27:27.000 --> 00:27:33.840
through embracing the DHS Playbook and integrating 
accessibility throughout all phases of the  

00:27:33.840 --> 00:27:39.540
development life cycle. The need to seek relevant 
developer accessibility training and guidance  

00:27:40.680 --> 00:27:43.980
on integrating test automation 
into the development environment.  

00:27:44.700 --> 00:27:50.640
And looking ahead to future training and support, 
several developers we spoke with raise the issue  

00:27:50.640 --> 00:27:56.160
that they often don't actually write HTML, that 
it's rendered by the framework or otherwise in  

00:27:56.160 --> 00:28:01.680
a black box. They also may not have access to 
change code provided by another team or even  

00:28:01.680 --> 00:28:08.820
another company working on the same project. I 
ran into that myself in the past, and that's worth  

00:28:08.820 --> 00:28:15.420
addressing for sure in real time. These situations 
need to be triaged on an individual basis due to  

00:28:15.420 --> 00:28:20.460
the variable development environments. Otherwise, 
when front-end code is available to modify,  

00:28:20.460 --> 00:28:27.120
utilizing best practices and coding techniques 
and coding in anticipation of Trusted Tester  

00:28:27.120 --> 00:28:32.940
requirements and outcomes from automated 
compliance reporting tools is the optimal goal.  

00:28:33.900 --> 00:28:39.060
AU will continue to explore methods to facilitate 
training and support for development through  

00:28:39.060 --> 00:28:45.420
continuing to explore accessible developer 
training, expanding Dev automation pilot  

00:28:45.420 --> 00:28:50.340
initiatives, and instituting a collaborative 
Message Board to share questions and solutions.  

00:28:50.340 --> 00:28:55.680
That's my favorite, as well as other trainings 
such as incorporating customer experience.

00:29:00.060 --> 00:29:05.700
Alan put together a simple roadmap to implement 
the Accessibility DevOps initiative presented  

00:29:05.700 --> 00:29:10.920
today. He suggested developers, in particular, 
should acquire the following skills and training:  

00:29:11.460 --> 00:29:16.260
knowledge of WCAG as described in The 
Trusted tester conform test process for web,  

00:29:17.220 --> 00:29:23.160
the ability to choose compliant ICT authoring 
tools, the ability to implement code  

00:29:23.160 --> 00:29:29.100
strategies that meet Section 508 and usability 
requirements while achieving ICT business need,  

00:29:29.880 --> 00:29:35.460
and the ability to efficiently implement 
Section 508 unit testing in the SDLC.

00:29:37.560 --> 00:29:43.980
To summarize, the primary training resources for 
development teams we covered today that align to  

00:29:43.980 --> 00:29:48.120
the Accessibility DevOps roadmap include 
the Trusted Tester training certification,  

00:29:48.840 --> 00:29:54.300
the DHS 508 Playbook, and the dev automation 
GitHub code resources and examples.

00:29:56.700 --> 00:30:02.340
That concludes my presentation. So, if you 
have questions or would like to access any  

00:30:02.340 --> 00:30:09.480
of the materials presented today, please write 
to or call the DHS accessibility desk. There  

00:30:09.480 --> 00:30:15.420
are also reference slides at the end. A 
few requests: a copy of the presentation,  

00:30:15.420 --> 00:30:21.840
you'll see at the end here, there are specific 
references to the information mentioned today.

00:30:23.600 --> 00:30:30.480
>> Thank you very much, there, Miss Lynette. 
We appreciate that presentation. It's full  

00:30:30.480 --> 00:30:35.640
of information, for sure. You do have a 
couple of questions. One that came in is,  

00:30:35.640 --> 00:30:43.260
do you experience Site Improve giving false 
flags on AA or A issues on your websites,  

00:30:43.260 --> 00:30:46.140
and if so, how do you resolve them?

00:30:49.400 --> 00:30:53.760
>> I'm sorry, I was still 
manipulating my computer.

00:30:55.460 --> 00:31:00.660
>> False negatives, yeah, that's... that's the  

00:31:02.760 --> 00:31:07.080
triage I was mentioning that needs 
to happen on an individual basis.  

00:31:07.980 --> 00:31:15.360
That is a very common problem, and I don't think 
we have the bandwidth today to address that, but  

00:31:16.560 --> 00:31:23.940
having the rule sets set up in advance and 
the scanning software is key to avoiding that.

00:31:26.600 --> 00:31:30.360
>> Good. Let me see if we 
can get to another one here.  

00:31:35.940 --> 00:31:39.960
So, what is the best... another question 
came in from Ms. Juanita Thomas.  

00:31:41.220 --> 00:31:46.860
What is the best way to present or promote this 
training to developers? Oftentimes, they are  

00:31:46.860 --> 00:31:51.420
apprehensive to go through the training due to the 
time, especially for the Trusted Tester training.

00:31:51.980 --> 00:31:58.560
>> You know, that was actually the impetus for 
Alan wanting to do the developer-specific course,  

00:31:58.560 --> 00:32:06.300
yep, so that it could kind of be a pick and 
choose by the table of content, um, and that  

00:32:06.300 --> 00:32:14.940
they wouldn't need to go through the structured 
path that the Trusted Tester track does.  

00:32:17.040 --> 00:32:27.480
But, um, I would have to defer to Nick on 
that. Um, there's, um, you know, I mean,  

00:32:27.480 --> 00:32:34.680
it goes back to literally the course content 
that was proposed, um, to address that issue.

00:32:34.680 --> 00:32:42.660
>> Understood. Understood. One other person, can 
you please go back to the reference slides again?  

00:32:42.660 --> 00:32:51.420
Sure, I think they were trying to capture 
that data. Oh, there you go. And remember,  

00:32:51.420 --> 00:32:56.820
these slides will be made available later. Um, 
if you would like to have them, you can always  

00:32:56.820 --> 00:33:04.920
send the emails again to accessibility@hq.dhs.gov, 
and we will provide that information to you later.

00:33:07.500 --> 00:33:09.000
See if there's any other questions.

00:33:11.160 --> 00:33:20.820
So, Lynette, dealing with the developer training, 
are you able to tell the participants when do  

00:33:20.820 --> 00:33:27.180
we think we will have an ETA on that 
being created and going out to folks?

00:33:27.180 --> 00:33:31.260
>> Yeah, I'll defer to Nick on that.

00:33:33.500 --> 00:33:42.300
>> So, folks, basically, that's the politically 
correct answer: stay tuned. Uh, we are going to  

00:33:42.300 --> 00:33:47.040
be working on that, and that will be something 
that will come out, you know, soon. Uh,  

00:33:47.040 --> 00:33:50.580
I am actually interested. How many people on 
the call right now, before we go into our next  

00:33:50.580 --> 00:33:57.420
presentation, are Trusted Testers currently 
or have used the Playbook? And if you have,  

00:33:58.560 --> 00:34:04.440
um, can you put in the chat, or 
the PB, because I'm just kind of  

00:34:04.440 --> 00:34:10.860
interested in seeing. Oh, a couple people 
say me. Okay, here you go. Interesting.

00:34:15.120 --> 00:34:19.920
Very good, a lot, a lot of Trusted Testers. 
A couple of people have used the Playbook  

00:34:19.920 --> 00:34:26.460
already. Very good, very good. Now we 
know that the Trusted Tester training,  

00:34:27.240 --> 00:34:31.620
um, is challenging, to say the least, uh, 
because, again, we're trying to make sure  

00:34:31.620 --> 00:34:37.740
that people really have a full understanding 
of how to test and what to look for. But now  

00:34:37.740 --> 00:34:42.120
that you have gone through the Trusted 
Tester training, do you feel that that  

00:34:42.120 --> 00:34:48.180
has made you more aware when it comes to 
identifying accessibility-related issues?  

00:34:49.200 --> 00:34:53.700
Um, and you can just put it in the chat, yes. 
Somebody says they want to be a Trusted Sister,  

00:34:54.960 --> 00:35:02.040
indeed. Okay, very good, very good. Very good. 
Now, one thing, and I'll just bring this one  

00:35:02.040 --> 00:35:11.040
last point up, we had a conversation within our 
office, um, the other day, and it is the fact that  

00:35:11.700 --> 00:35:17.820
a lot of people are doing Trusted Tester training, 
but they may not know how to report. So, the ACRT  

00:35:17.820 --> 00:35:24.780
is the report that you can utilize if you do not 
know how to properly use the ACRT or have access  

00:35:24.780 --> 00:35:31.200
to the ACRT, please reach out again to our office, 
and we will be glad to provide you that level  

00:35:31.200 --> 00:35:38.160
of support to ensure that you have a reporting 
mechanism for your post-Trusted Tester reports.

00:35:38.160 --> 00:35:42.600
All right, Lynette, I don't know 
if there's any other questions. Oh,  

00:35:42.600 --> 00:35:46.800
there you go. Thanks. Thank you so much. 
Savage has put in the link for GitHub,  

00:35:46.800 --> 00:35:52.740
how to get to the ACRT for a test report. And 
again, if you don't know how to use this report,  

00:35:52.740 --> 00:35:58.680
uh, we definitely will provide you with that 
information. Uh, if you don't have any other  

00:35:58.680 --> 00:36:03.900
questions, I want to say thank you so much, Miss 
Banning, for this great presentation. Thank you.  

00:36:03.900 --> 00:36:10.680
It was my honor to present work that Alan King 
worked very hard on. Yes, he definitely did,  

00:36:10.680 --> 00:36:16.980
and you served him well in honoring him today, 
and you did a great job of presenting this  

00:36:16.980 --> 00:36:22.140
information. So, uh, and we will continue to 
keep working in his honor, uh, moving forward.

00:36:23.480 --> 00:36:26.340
>> Thank you so much. Bye-bye.

00:36:26.340 --> 00:36:31.980
>> Bye-bye. All right, guys, 
we actually are at our break,  

00:36:33.060 --> 00:36:37.020
so I like to do that, you know. I don't really 
do sign language, but I try to. I think I'm