Accessibility Coaching: A Peek into the Playbook

[amazonv]

Accessibility Coaching: A Peek into the Playbook

Type: Breakout

Track: Organizational Success with Accessibility

In the fast-paced world of building digital user experiences, how do you continually keep Accessibility top of mind for pressured Product Owners, time-strapped Testers, and all of the team members in between? This presentation will give you a look at how Accessibility Coaches could be the answer.

 

Y'all can get a free copy of the book Kelly mentioned: 'A Practical Guide to Accessible Software Development at Scale' https://accessibility.deque.com/agile-accessibility-handbook

 

  And one thing before we 

         dive in, I just want to say it's become really pattern 

         throughout the conference that we are all at different places 

         with our organizations and our organizations journey's toward 

         accessibility.  

                  And so I hope that this peek in the playbook gives 

         you a peek into ours, but also maybe helps you with yours.  

                  So with that, let's talk about the beginning.  Which 

         for us was just a couple of years ago.  We started to work on 

         accessibility with full-time employees, just a few years 

         back.  And what quickly came to the surface was that we had a 

         lot of teams, right?  We have dozens of teams that work on 

         front end digital experiences for our customers.  Hundreds of 

         team members, right, those front end teams are made up of 

         hundreds of people.  And they all have questions, right?  

         With accessibility and web accessibility being a new concept.  

         We learned very early on that we had lots and lots of 

         questions.  And what we didn't have was a lot of expertise to 

         be around.  So it became apparent that we needed to sort of 

         think about how we were going to tackle such a big problem 

         that had so many people sort of involved.  

                  And as I have been listening to other presentations, 

         I've heard people from other big and small organizations say 

         the same thing, right?  Wow.  A lot to think about.  So I 

         know that is not unique for us.  

                  And let me just give you a feel for what we started 

         to do in the beginning.  We had training set up.  So we were 

         able to leverage some training resources to get our teams 

         familiar with the web content accessibility guidelines.  

         Familiar with the foundations of accessibility and some of 

         the basics.  We had some basic training.  Sort of settled.  

         We also had basic browser extension tools that we were able 

         to use.  

                  We very early on partnered with decue, which if you 

         are not familiar with that tool, it's sort of like one-stop 

         shopping for articles and resources on accessibility we think 

         of it as a safe place to search different accessibility 

         topics and get information that has been thoroughly vetted.  

         We leaned on that Duke University tool in the beginning 

         particularly.  

                  We were able to do automated and manual testing and 

         let our teams know different, through different metrics how 

         they were doing in terms of accessibility.  So again, we had 

         training, weed tools.  We had Duke University and we had 

         audits.  What we didn't have was an abundance of specific 

         information for teams who were using all of that, right?  So 

         we could hand you an audit and say here you have X number of 

         issues, but we didn't have a lot of ability to help you 

         through those issues one by one, especially if they were 

         complicated.  If you had visuals that just needed a lot of 

         TLC to get them to an accessible place.  

                  We started to feel like maybe it wasn't enough.  And 

         we kept coming around to this, how can we support these teams 

         more, what else can we do.  

                  And when we say teams I want to talk just for a 

         minute about what teams mean for us.  Our -- we use agile, 

         and on your screen I have listed out the roles that we focus 

         on from an accessibility perspective.  We designers, our 

         masters, our product owners, our business systems analysts, 

         so I mentioned we use agile, for us, BSAs write the 

         requirements that are part of that.  We have testers, front 

         end developers and then content writers.  Each of those 

         people has sort of a different role to play when it comes to 

         accessibility.  And as we thought about how to really help 

         each of them, we were thinking about those individual roles.  

                  So on your screen right now a quote that we used 

         very often in those early days, right?  We wanted to teach 

         these teams to fish.  If you give a man a fish, he eats for a 

         day, if you teach a man to fish, he eats for a lifetime.  And 

         we wanted these teams and these people on these teams to 

         learn how to do accessibility in their roles and to be able 

         to use it for their customer experiences, and then also take 

         it with them.  

                  So you know, we sort of joked within our team, we 

         should have this on T-shirts and bumper stickers and laptop 

         stickers, we said it so much in the early days.  

                  But it really rings true.  And I've got a graphic 

         here, beautiful artwork of fish in a hook.  Because again we 

         just used this all the time in the early days.  And I bet 

         some of you use it, too, I've heard it mentioned in 

         accessibility circles. 

                  So that was it.  How do we teach the teams to fish?  

         So we started kicking around the idea of embedding subject 

         matter experts into these teams.  Or embedding means into the 

         teams.  And we were able to run a little pilot.  We had one 

         subject matter expert who we were able to put on to three 

         teams.  

                  And one of our earliest lessons learned was if we 

         put a subject matter expert on a team, it might imply that 

         the work is going to be done for the team, right?  That they 

         are going to come in, and they are an expert on 

         accessibility, they are going to do it for us.  Actually, 

         that is not the message we were trying to get across, so very 

         quickly we changed our terminology a little bit.  

                  Actually, Ben Alan, who some of you might have seen 

         present yesterday, was reading Dil and bear row, he has a 

         book called agile accessibility explained.  What he was 

         describing in that book he called the subject matter expert a 

         coach.  And a coach was a way better way of describing the 

         subject matter expert.  And we liked it and jumped on it. 

                  And so what is on your screen is just the definition 

         of a coach, right?  A coach is a person involved in the 

         direction instruction and training of the operations of a 

         sports team or of individual sports people.  Coach may also 

         be a teacher.  

                  And so we dispatched two accessibility coaches on to 

         a handful of teams.  And you know, again, the thought was you 

         are not going to do the work for you, they are going to teach 

         you how to do the work.  And so for a second I want everyone 

         to take that accessibility cap off and maybe just put your 

         nostalgia cap on.  I want you to think about a coach who has 

         been meaningful to you or a teacher who has been meaningful 

         to you, or a coach who has been meaningful to your favorite 

         team.  

                  If we pause for a second, someone and probably 

         popping into your mind.  And I couldn't resist the 

         opportunity to put my favorite teacher from the journalism 

         school on the screen.  Because he is a teacher who sort of 

         comes to mind for me when I think about teaching.  

                  And we wanted to really drive this point home with 

         teams, that they are not going to do it for you.  But they 

         are going to show you the way.  

                  And so all right.  Accessibility cap is back on.  

         College nostalgia put away.  And we'll kind of dive into our 

         model.  

                  Okay.  So what we have here, and I will read this 

         for you guys, is just some of the basics of this model.  

         Right?  What is the coach actually doing or how are we laying 

         this out for teams, and so again, they are introducing the 

         concepts, basic accessibility concepts to teams.  We know 

         that the basics were needed, and so that is like A number 

         one, right?  We were also asking them to spend time with the 

         teams at each person on the team who had a role to play in 

         accessibility to really understand their job.  We didn't want 

         to come in and say, there is this one size fits all approach.  

         Weapon wanted to have the coach come in, and sort of talk to 

         people about how they built their front end experiences.  

                  So that kind of goes into learning how the team 

         operates.  And figuring out how best to integrate 

         accessibility within the unique teams.  We are introducing 

         concepts, we are talking to people and team members one on 

         one, and we start to show up where they are, right?  We start 

         to provide feedback on their designs.  We start to work on 

         front end user stories.  As I mentioned, those users stories 

         are written by BSAs, so a lot of one-on-one time in the early 

         days with the BSAs.  

                  And just sort of mention it here in those early 

         days, there is a lot of work for the coach, right?  We are 

         starting to set the groundwork for -- to transition on to the 

         teams.  So while you heard me say well we are not excepting 

         that the subject matter expert or coach is doing the work.  

         In the early days there is a heavy left for this coach.  Or 

         for these coaches.  But again, it is to sort of build the 

         foundation over time.  

                  So again, just to recap this one, we are introducing 

         the concepts.  We are trying to build the trust.  Learning 

         how the team operates.  Starting to provide feedback on 

         designs.  Starting to be involved in refinement forefront end 

         user stories.  Starting to build and write accessibility 

         focused user stories.  And then just recognizing that it's 

         heavy on the coach at first, but again about building the 

         groundwork.  

                  Okay.  So common question that started to come up 

         again in our little experiment with two coaches and a couple 

         of teams.  Teams would say, hey, you know, we know we've got 

         a lot of accessibility issues.  But we also are working on 

         new features.  So what do we do first?  Focus on the new 

         stuff, how should we do this.  So again in that same vein of 

         we wanted T-shirts that said this, how do you get yourself 

         out of that hole with accessibility deck, you have to stop 

         digging you, you have to put down the shove vel.  Stop making 

         the same mistakes over and over again, and that is where the 

         coaches came in was to help the teams to stop digging the 

         hole.  

                  So we'll talk more about that.  But again, a really 

         common phrase that we felt we were saying every day in the 

         beginning is just we want to stop digging.  We want to help 

         the teams in the roles to stop digging.  

                  So again, our very early steps, very early tactical 

         pieces that we had to do from a strategy perspective was we 

         needed to find product owners who might be interested in 

         this.  So we sought out volunteers, because we knew that 

         timing was an issue, right?  

                  A lot of pressure, a lot of deadlines, a lot of 

         moving PAFRTs for teams that are responsible for customer 

         experiences, so the time is not always right for everyone.  

         So those were some of our early steps or considerations.  

                  And then once like I said we had found product 

         owners who felt like the time was right for them and we had 

         the volunteer teams, we would have the coach on all of the 

         ceremonies, so again we use an agile framework, that meant 

         they would be on stand up every day.  We are not like a 

         casual observer, our coaches are on stand up every day, in 

         finance or grooming, in the retrospective, in the demos, they 

         are showing up across the board in team ceremonies.  We tried 

         to allow time for them to observe.  

                  We don't hand coaches a piece of paper that says 

         here is how you are going to execute with this team.  The 

         time is built in to learn the team.  

                  And again, we are trying to identify places where 

         opportunities exist.  So design meetings for example.  That 

         rose to the surface early, that their teams have different 

         ways that they meet regularly on designs, but if we can get 

         those coaches in there, it certainly is a great place to 

         start to talk about accessibility.  

                  And then also we have one-on-one meetings.  It's one 

         thing for the coach to show up in ceremonies and meets and be 

         a fly on the wall, but they also have to start one-on-one 

         with each of the roles.  

                  So again early first steps, socialization with our 

         product owners.  Seeking volunteer teams.  Making sure the 

         timing is right, and then some of the logistics around 

         getting the coach on ceremonies, having them set up 

         one-on-ones, and then showing up in some of the forums where 

         there might be some opportunities.  

                  All right.  I have heard quite a few people over the 

         last couple of days talk about shift left.  So I won't 

         belabor this too much, but just in case this concept isn't 

         familiar to you, I want to talk about it just for a second, 

         because it's really relevant here, and it was really relevant 

         for our coaching program.  

                  So shift left is basically a practice intended very 

         common in software development to help find defects early in 

         the software development life cycle.  

                  And so what I have on your screen is just that 

         definition.  The idea is to improve quality by moving tasks 

         to the left.  Shifting left as far as possible.  And of 

         course when you do that, when you move left, under the 

         accessibility umbrella you are making it a lot easier and a 

         lot cheaper to fix your accessibility problems. 

                  And the analogy that I was going to use, I also 

         heard today, so this must just be a common one, think about 

         building a house.  Right?  If you sit down with your 

         architect and meet regularly with the people building your 

         house, at the end when you arrive at your house to move in, 

         the pieces and parts are probably going to be accounted for 

         if you had regular conversation along the way.  

                  If you get there and it's moving day, and you 

         suddenly decide that you want a sky light, and you want a 

         door and you want an additional window, can it be done, sure?  

         Is it going to delay things?  Is it going to be expensive?  

         Is it going to be time-consuming?  Yes.  So again shift left 

         is an early concept that we are trying to explain to our 

         teams through our coaching program, just because again if 

         that coach can start to show up in those early conversations, 

         wherever they might fall, it's going to make a difference in 

         the long run.  

                  Okay.  So in the meantime, while those coaches were 

         getting up and running with those teams, the digital 

         accessibility operations team that I work on sort of had its 

         work cut out, right?  Because while the coach was showing up 

         in ceremonies, and the coach was working on the individual 

         experiences, we had to get some things together and we were 

         up and running.  This was in flight.  So we were working on 

         creating documentation.  

                  We were working on meeting with those coaches very 

         regularly to find out what do we need to write down for you?  

         What do we need to write down for your teams?  What lessons 

         are starting to evolve here.  We created documentation on 

         tools.  Even just how do you get them, right?  We are a big 

         organization.  There is a couple of different systems that 

         you would use to get different tools.  And so we needed to 

         get it all written down.  How do you put the requests?  Where 

         do you go for them?  How do you get this that or the other 

         thing.  So documentation around tools.  

                  We needed to get written down measures of success 

         within these teams, right?  We've got the coach there.  They 

         are showing up.  It seems like it's going well.  We are 

         getting a lot done around informing people about the basic 

         concepts, but how do we measure if we are moving the needle?  

         We got to work on mile stone documents.  And worked with the 

         coaches to say, what would be a good measure of early 

         success?  What is a good way to know that you are starting to 

         make in roads with the team.  We created mile stones.  

                  There was a team already in flight that I think 

         really started to kick up its efforts around this same time 

         to create an accessible component library.  Again, a concept 

         that we talked about throughout this conference.  We needed 

         one.  And so a team that had already been formed started to 

         really hit the gas on getting that component library built 

         out.  And we wanted to get an acceptance criteria library, 

         also built, right?  

                  Because as I mentioned at the very beginning, a lot 

         of teams, a lot of people.  So what usable pieces and parts 

         can we create that they can use that will make their life 

         easier, that they can have confidence about accessibility 

         with and that component library and the acceptance criteria 

         library sort of came together around that time.  

                  And then of course $64,000 question, how do they 

         know when they are done?  It's not -- it's never what is on 

         the surface, right?  It's never just passing some automated 

         tests.  There is always more to it.  We had to spend time on 

         the definition of done which we are going to get into.  

                  Documentation was big on what, on tools, documenting 

         mile stones, documenting that component library, the 

         acceptance criteria library. 

                  At the same time you heard me mention we had some 

         general training.  We had some foundations training.  We had 

         some introductory training.  So it became very apparent to us 

         that we needed to invest in some roles-based training that 

         pertain specifically to our organization.  That took into 

         account nuances that existed for us.  

                  So we spent a considerable amount of time and effort 

         making sure that the training that was available for our BSAs 

         struck the right balance for them given the pressures and 

         different things that exist for them in their day jobs. 

                  So crafting roles-based training was a big part of 

         our early coaching program.  Because for as much as the 

         coaches could guide different roles in their day-to-day, we 

         also wanted everyone to be able to step out of their 

         day-to-day, to come into some instructor-led training that 

         was really pertinent for them.  We wanted no one to leave 

         with any question about how does this pertain to my day job?  

         How do I apply this?  So like I said, we put a lot into that.  

                  And then again, regular touchpoints.  You heard me 

         talk about, okay, we asked the coach to have regular touch 

         points with each of the team members.  What we didn't 

         initially have set up that became very apparent, again was 

         that somebody from the strategy team, or the operations team 

         needed to be talking regularly with the product owners.  So 

         that, again, we could get the documentation that they felt 

         like they needed.  And the information that they felt like 

         they needed, sort of accounted for in our program.  

                  And then another thing that was coming together 

         around this same time was we needed to build up an automation 

         program.  We needed some tools, and we needed some focus in 

         the automation space.  

                  And so that was all happening as our coaches were up 

         and out there working on customer experiences.  

                  So you heard me mention the definition of done.  And 

         what we came up with, what is relevant for our organization 

         is sort of listed out here.  So the first thing that we 

         wanted to be taken into account was just that you had 

         100 percent automated accessibility test coverage in place on 

         your experience.  

                  So what this means is if you are a product owner or 

         you are a QA, you've got to have the automation set up before 

         you are done with our coaching program.  

                  And so that is our first piece.  And you heard me 

         just mention a second ago, right, we had to get that program 

         together and if the program is not together, we can't expect 

         that to be set up, so that some of this was happening in 

         tandem.  We were getting the tools in place so that teams 

         could get that automation stuff settled.  

                  The other way that we would measure if you were done 

         was if, again, everybody member of your agile crew knew how 

         to incorporate accessibility requirements, knew what they 

         needed to do and was meeting the milestones.  

                  And we'll talk about some challenges to that in a 

         minute.  But again, that was something that we just felt 

         really was important before you could be done.  You had to 

         have that taken care of.  

                  And then from an accessibility perspective the 

         digital experience and the crew is taking responsibility for 

         being release ready, and for having a plan for accessibility 

         debt.  

                  So if you are sort of imagining how this is all 

         unfolding, for quite a while you are working with your coach 

         and nor, working on front end features and you are working 

         toward a release date.  And so again for us release ready is 

         no critical, no serious issues.  

                  And that you have a plan for the other issues that 

         might exist.  And so that is a piece of our definition of 

         done is release readiness and a plan for accessibility debt.  

                  And then finally, you know, we require that the 

         product owner really has a strong grasp around ongoing 

         monitoring and accepts the timelines connected to 

         accessibility debt and to ongoing monitoring.  Another strong 

         theme that I've heard in this conference and that is part of 

         my work is just that you are never done.  You are only as 

         good as your last release, and the accessibility journey 

         never ends.  And so we really felt like we needed to make 

         sure that that was a really crystal clear concept for our 

         product owners, and that when your coach rolls off the team 

         they are still monitoring and they are still involved with 

         us. 

                  So that is our definition of done.  It's different 

         for everyone.  But that is sort of how things had shaken out 

         for us.  So many, many lessons learned.  I've just 

         highlighted a couple of them.  

                  One of them was easy.  We realized that we were 

         talking to people a lot about coaching, and we needed them to 

         do some paperwork for us.  Right?  And so we needed to 

         understand the roadmap, their tech staff, maybe about their 

         crews, so we established an onboarding questionnaire.  

                  It's easy.  A Microsoft Word document, hey, sure, 

         you are interested?  Take this onboarding questionnaire.  

         Read about our program.  Give us a little information about 

         you.  And we'll use it to sort of, to both of our advantages, 

         right?  

                  So that was a quick lesson learned that we were able 

         to adjust to fast.  Team churn is not something that is easy 

         to solve.  And we kind of call it the achilles heel of the 

         coaching model.  And it's a problem for many companies.  I 

         mean, probably every company to some degree, right?  And so 

         it falls right into our accessibility coaching pile, right?  

                  You are right near the finish line, and BSA leaves 

         the organization.  You had them trained, they were writing 

         stories, they knew how to account for everything.  And they 

         are gone.  And if we are using a sports analogy here, because 

         we are talking about coaching, right?  Who is your quarter 

         back going into the super bowl.  You have a real problem on 

         your hands.  We have recently been working on this one.  And 

         kind of leaning on existing team structure, right?  When 

         someone rolls off an agile team or leaves an agile team and 

         someone new comes on, there is an on boarding process they 

         have. 

                  We have been working to try to get accessibility 

         baked into that on boarding process.  Not reinventing the 

         wheel, but making sure that that new BSA has access to 

         upcoming training.  

                  And has access to a lot of the documentation that 

         you heard me mention.  So we can sort of combat some of that 

         with a regular training calendar, and then also 

         documentation.  Good documentation.  

                  But again, work in progress.  This is another thing 

         I mentioned, but I just don't want to undersell the value of 

         really regular touchpoints between our operations team that I 

         work on, and the product owners and coaches.  So right now 

         they are bi-weekly touch points.  Some teams that are close 

         to roll off or maturity, we are pushing those out.  Again 

         that regular communication really became vital for us, and 

         just a lesson learned over and over again.  

                  And then we needed our coaches to have some 

         documentation.  You heard me talk about documentation for the 

         people using the tools.  Or the, you know, the component 

         library would be usable we needed to get some stuff written 

         down for coaches for the sake of consistency.  And then to 

         really tie the pieces and parts of this program together.  

                  So those are some of our early lessons learned.  I 

         could probably do a whole presentation on lessons learned.  

         But again, those are the ones that we sort of wanted to call 

         out.  

                  So to sort of recap, I have ended with a to be 

         continued slide, because there is a lot that we are still 

         working on.  But I hope that that gives you a little bit of a 

         peek into the playbook, and super interested in questions.  

         And just having a little dialogue here about what we are 

         starting to get together.  

                  >> Many thanks, and the questions are definitely 

         coming in.  We have about 20 minutes.  Emily asks, what went 

         into the decision to take an outside coach and integrate into 

         the teams instead of identifying someone already on the team 

         to champion or own accessibility for their team function?  

                  >> Sure.  Some of it was capacity.  Our teams have 

         quick turnaround, a lot of existing pressures on them.  And 

         so we saw an opportunity to bring experts in, as opposed to 

         making experts out of people.  So that was the way that 

         worked for us was that we weren't really in a position to 

         create those champions within the teams at that time.  

                  And again, time can be of the essence, right?  I 

         feel like that is one of my buzz words today.  But for us, we 

         needed in some places to move quickly, and so rather than 

         yanking someone out of their team who had the whole day job 

         to do, what worked for us was to eninexcept expertise. 

                  >> How did the cultural impact the job 

         responsibilities of the coaches?  Were the coach's roles as 

         dedicated or were they also balancing their own development 

         responsibilities?  

                  >> No.  So these coaches did not have development 

         responsibilities.  We didn't pull developers out and make 

         them coaches.  We brought accessibility consultants or 

         subject matter experts in.  And I think we feel pretty good 

         about the way that that is unfolding, because again their 

         sole focus is accessibility.  So if you need that expertise, 

         whether you are a designer or developer or any of the roles, 

         you have it.  And someone doesn't have to worry about 

         anything else, right?  This is the cool part of it, is that 

         that is the model that we are using.  

                  >> Okay.  Next question.  If you can share where 

         does the accessibility program and coaching model live within 

         the organization?  Does it stem from development design QA 

         testing?  

                  >> Yeah.  So it's none of the above.  It's actually 

         in our digital organization.  And so under sort of the 

         product management umbrella is where digital accessibility, 

         the operations team and the coaching program sits.  Close 

         partners, of course, with developers and QA.  But in terms of 

         organizationally, it's within the digital organization.  

                  >> Okay.  Great.  Next question.  How easy or 

         difficult was it for teams to embed a coach into their sprint 

         ceremonies.  

                  >> Well, easier for some than others.  That is why 

         especially in the early days we tried to really vet their 

         availability for that.  And now that we have grown and grown, 

         we are past a place where we are like hey if this works for 

         you, we want to put a coach on your team, right?  Now we 

         are -- our program has grown enough where we are proactively 

         putting coaches on teams because we need to move the needle 

         on their products.  

                  So some very smooth transitions, others a little bit 

         harder.  Especially on those ceremonies, right?  Because 

         teams develop norms, and teams get close and teams get their 

         dynamics going.  So again I feel like I keep saying the word 

         time over and over again, but that is something that helps 

         when there is a little bit of friction, which will happen 

         occasionally.  We are not telling this coach to come in and 

         start anything quickly.  We really are building things in for 

         them to adjust to team norms.  

                  So I hope that answers that question.  Some easier 

         than others.  

                  >> Yup.  Have you gotten to the point where your 

         teams are fishing independently?  What happens to the coach 

         then?  

                  >> Yeah.  So we are pretty close on that.  Which is 

         really exciting for us.  And the coach rolls off.  Once we 

         have met that definition of done, and once the milestones 

         have been met, the coach does roll off, and rolls on to the 

         next team.  

                  And so we are excited about that.  Because that is 

         like right where we are right now.  Is we've got teams that 

         are doing it on their own and doing it well.  

                  And so, yeah, the coach does roll off.  

                  >> And Kelly just to add to that, is that a case 

         where you are working in parallel and getting teams in the 

         queue so the coaches do roll off, they have other teams they 

         are jumping on. 

                  >> Exactly.  That is a big part for us is just 

         making sure that that is smooth in the end, that the 

         transition is smooth, but that also teams, you know, that 

         might have, you know, be next in line for prioritization get 

         that coach, right?  That those situations or experiences that 

         really need the focus have the opportunity to get it.  

                  >> Right.  Great.  Lorraine asks, if you don't cover 

         it, I would be curious to know how you host or publicize your 

         acceptance criteria or AC library, we are building one up 

         now, but it's not very discoverable.  

                  >> So I'm thinking that this is how do we publicize 

         it internally, it sounds like.  

                  >> Yup.  

                  >> And that is a great question.  So our coaches 

         play a big role in that, right?  Because they are talking to 

         the BSAs, and it's our BSAs who are using the library.  The 

         coaches play a big role in that.  And I would say that is 

         probably the long and short of it, is that as coaches go on 

         to more and more teams, they are teaching more and more BSAs 

         about how to use it.  

                  It is a big part of our BSA training curriculum also 

         how to use this library.  

                  So the coaching program goes hand in hand with the 

         use of the AC library.  

                  >> Okay.  Great.  Next question, at what point does 

         the heavy lifting start to transition off the coach and the 

         team starts to take responsibility for accessibility 

         requirements themselves?  

                  >> Yeah.  So we like to break things out into chunks 

         around like three-month pieces.  And so we start to see that 

         shift in independence generally, some teams go faster than 

         others, and some teams have more capacity of band width than 

         others.  Some of them you will see quickly shift because they 

         have sort of the availability to quickly shift.  But 

         generally about three months is where we start to target 

         that, the shift of the responsibilities.  

                  >> Okay.  Great.  Next question.  What about product 

         owners who push back against the idea of a coach or 

         prioritizing accessibility, but their content is creating a 

         big risk for PNC bank.  How do you navigate that 

         relationship?  

                  >> So I would say you navigate it delicately.  And 

         that is probably where empathy comes in.  I think if that 

         happens, you know, a demo of the product with a screen reader 

         user is a great way to sort of demonstrate maybe some of the 

         realities that they might not be aware of. 

                  Another thing we have done is we have done empathy 

         labs.  And we bring our product owners in so they can use 

         some of the equipment that is brought in for an empathy lab 

         to sort of walk in the user's shoes.  I think when that 

         scenario comes up, if we tackle it from an empathy 

         perspective, that usually does the trick, right?  

                  And it is really beneficial for them to see their 

         own product, you know, from a different lens.  And so that is 

         a technique that we used, and I think had some success with.  

                  >> All right.  Great.  And just a reminder, if you 

         do have questions, be sure to put them in the Q and A tab as 

         opposed to the chat tab to make sure we have visibility on 

         those. 

                  Next question.  Aid Dan asks, do you give any push 

         back training contractors, if so, how do you overcome this?  

                  >> I'm not sure if I can talk about that.  So I'm 

         going to skip that one.  And take the next one.  

                  >> You got it.  Emily has another question.  You 

         mentioned turnover.  How are new team members onboarded and 

         trained on accessibility after a coach is done with that 

         team's engagement?  

                  >> Yeah.  So we are working on that right now.  And 

         that is where we are starting to work closely with our 

         masters, right?  So new BSA comes in, they've got to learn 

         about the customer experience tied to that product.  They've 

         got to learn about the norms of the team tied to that 

         product.  So we are working on getting accessibility tied 

         into that onboarding within the product teams.  

                  And it's like a hot topic for us right now.  That we 

         are sort of aggressively looking at, because team turn is 

         happening.  And we are kind of staring that one down now and 

         working through it.  We are seeing some promise with sort of 

         working it into other norms for new team members joining. 

                  >> Okay.  Say your company's roadmap is a detailed 

         multi-year plan, meaning no good time to disrupt product org 

         with integrating accessibility.  How do you demonstrate the 

         value of prioritizing that education, maturing the product's 

         excellence in standards and adding some extra steps to SDLC?  

                  >> Great question.  And I think what I just 

         mentioned about the product owners applies to leadership as 

         well.  And so when we had our empathy lab, you know, our 

         chief retail officer joined us for the empathy lab.  We had 

         other senior-level executives join us for the empathy lab. 

                  So that has really helped us at our organization 

         shine a light on accessibility.  We are lucky, in that we 

         have a leadership team that is brought in and then some.  But 

         we've also brought them along in some ways, and brought them 

         into the empathy lab.  You know, we've sat down.  You know, a 

         few times to really talk in smaller groups with them.  And so 

         it's tough, but I think the empathy gap and sort of shining a 

         light on that has been a good place for us to sort of take 

         it.  

                  But great question.  And certainly very relevant.  

         Probably for everybody at this conference really.  

                  >> Yeah.  Jeff asks, if coaches roll off, how do you 

         ensure standards don't erode over time?  

                  >> So that is that monitoring program I talked 

         about, right?  The definition of done our last piece of it is 

         that product owners are accepting responsibility, for all 

         their accessibility debt and then for an on going monitoring 

         program.  

                  And so you know, again, great question.  And one 

         that we've sort aggonized over.  If you have someone 

         constantly reminding you about accessibility and they go 

         away, how do you keep it top of mind for everyone.  How do 

         you keep it relevant.  We think one of those ways is -- and 

         we through monitoring there is going to be regular contact 

         because of that and we are looking at other options beyond 

         that.  We don't have a champions program right now.  But we 

         certainly like to get that up off the ground.  We know that 

         there is a lot of success that other groups have had with 

         accessibility champions programs.  

                  And so that is something we are looking at.  Again, 

         you know, not there yet.  So we sort of right now lean on 

         that monitoring program.  

                  >> Okay.  Another question.  I'm curious, how many 

         coaches did you start with?  Did that change and if so why?  

                  >> Yeah we started with one.  We started with one 

         coach.  Its grown quite a bit from there.  And it changed 

         because we were successful with it.  And we had I think good 

         backing from leadership to allow more coaches to come on.  

         Right?  We had some great feedback.  We made early changes.  

         We were having success and so we had the backing to bring 

         more coaches on.  And so that is what we've done.  

                  And so it's grown quite a bit.  But we started with 

         one.  We had to see if it worked.  

                  So, yeah.  

                  >> Awesome.  Could you give some tips on how to 

         build an empathy lab for an organization?  

                  >> Yeah.  So for us, DQ did it for us.  And so you 

         could follow up with your friendly neighborhood DQ 

         representatives on where the empathy lab stands.  

                  And so I can't speak to that too much.  That was a 

         way that we used our partnership.  And they came in and did 

         do it for us.  So check with DQ on that.  

                  >> Great.  How large is the operations team and the 

         coaches team?  

                  >> Yeah.  So the operations team is basically myself 

         and three others.  And remember, we are on the strategy side 

         of it.  So that is not counting all of the people on the 

         product teams who are working on it, but our operations team 

         is for and then we have I would say 14 coaches right now.  

         And that is growing.  We are actually hiring more coaches and 

         so if that is something that you are interested in being a 

         coach, you know, we have two reps out right now, one in the 

         mobile and one in the web space. 

                  So would encourage you to check that out on 

         PNC.com's hiring site.  

                  >> What sort of support do you offer your coaches?  

         Who do they report to?  

                  >> Yeah.  So our coaches report to my boss.  So 

         basically the operations team and the coaches report to our 

         director, Ben, who again many of you had the pleasure of 

         seeing his presentation yesterday.  And we have a series of 

         things, we have a daily stand up, one on one meetings, weekly 

         deep dive, and then of course we have those touch points that 

         you heard me mention.  

                  So a lot of times if a coach is having any type of 

         blocker, it will come to the surface during those touch 

         points with product owners.  Or we tried really hard to just 

         have the lines of communication be very wide open for that.  

         And so again we have a daily stand up.  We have a weekly deep 

         dive.  We have a matter most channel.  And we have sort of in 

         those regular touch points with the product owners and the 

         coach to try to surface anything or provide support if it's 

         needed. 

                  >> Next question on diversity.  How does the coach 

         answer questions from three different roles that require 

         different expertise, questions from design, development, and 

         testers?  Those with different disciplines with different 

         needs.  

                  >> So great question.  And our coaches are experts.  

         They know the ins and outs of the accessibility requirements.  

         And so that is a great place to start in terms of their 

         overall understanding.  

                  And they've got various backgrounds from we have a 

         couple of people with design background, development 

         background, most have worked on agile teams at other 

         environments before joining our team.  So they are pretty 

         familiar with those basics.  But again, it kind of goes back 

         to the requirements, right?  They know the requirements 

         impressively.  So from what I've seen they are able to kind 

         of use that expertise that they are grounded in and apply it 

         in different ways.  We built up the coach's playbook.  We 

         have built up some mentor ship.  We recently brought someone 

         skilled into a coach of coach's role.  Because he was really 

         seeing how it was working well.  And so we sort of have 

         someone now, a coach who is working with the coaches.  

                  And that is another probably really important lesson 

         learned in terms of that overall support.  

                  >> All right.  We have just a moment, a minute left.  

         One more question.  How do you handle turnover on the product 

         teams?  For example if half the teams were trained and 

         coached, move on to and new people join after the coach has 

         left?  I think you did address this within your presentation, 

         but maybe just talking a little bit more about what that 

         looked like.  

                  >> Sure.  So one of the things that we have done 

         over time is that really solid documentation, right?  So 

         we've got a lot written down for them.  That is one thing.  

         So you are not coming in to a new team without anything that 

         you can read up on.  

                  Not that reading up on it is everything, right, but 

         again, solid documentation to point them to is a good place 

         to start.  We have a really regular training calendar.  So if 

         you are a BSA who is new to a team, who is unfamiliar with 

         accessibility, you can go out to our training calendar, take 

         a look.  When is the next training session.  And then get 

         yourself signed up for it.  

                  And then I think I hit on this, but again the scrum 

         masters are helping us to bring that together.  If you come 

         on to a new team, there is all sorts of things you need to 

         learn, accessibility is just one of them.  We are trying to 

         establish it as a norm enough so that again when people come 

         on, and they have to learn about various pieces and parts of 

         the role, the team has come along far enough in accessibility 

         that it's just another piece of it.  

                  And we can point them towards the documentation, get 

         you trained.  And start to bring along.  I think a lot of 

         people are asking the question, because it's a really very 

         real one.  And it's very real for us right now, too.  

                  >> And I think that is where we will have to leave 

         it.  Apologies for the questions that we couldn't get to.  

         Kelly, we really appreciate your time.  Thank you so much for 

         a great session.  Thanks to everyone who attended, and enjoy 

         the rest of the Axe-Con conference.  Bye now.