Agile Accessibility Requirements at Scale

[amazonv]

 Agile Accessibility Requirements at Scale

Type: Breakout

Track: Development

Discover how PNC incorporate accessibility requirements into their Agile practice. Learn about component libraries, acceptance criteria libraries, and the impact of these tools on the software development life cycle & accessibility training.

 

Ali: hi everyone my name is Ali Kawsan with Deque coming to you live from Ann Arbor and its an honor to bring to you development agile accessibility is recorded that skill with Ben Allen. Today's session is being recorded and will be hosted on demand for a lastly we will save the last 10 minutes for session Q&A. Please post your questions in the Q&A section and with that I will hand the floor over to Ben.

Ben Allen:  thank you Ali. It's a pleasure to join you all today it's a pleasure to be joining axe con I'm going to be talking but agile accessibility requirements at scale and my goals are two. Number one accessibility for writing accessibility requirements and number two I really want you to understand or get a sense of the tools we have developed at PNC in order to write good accessibility requirements. We have got quite a lot to cover today so I'm going to get straight on with it.

So my name is Ben. I managed a team of accessibility professionals at PNC. We support over 60 agile crews. So we have got a lot of teams to support and a lot of accessibility requirements to write. So that is a big challenge.

 The way that we do that, we are not just focused on creating accessible product . We are also focused on changing the habits of the team and we know that by changing the habits of the team we are going to get a more accessible sustainable program with PNC we will get teams were able to build and maintain accessible products and get accessible experiences for the customers.

 The way that we do that is we use an accessibility coach model. So what does an accessibility coach do? what they do is they join an agile team. They are part of the crew. And they try to understand how accessibility requirements affect each of the roles within that agile crew. And then they teach the team to fish. They teach them all about how to introduce accessibility into their roles. So the team as a whole is building with accessibility in mind.

So how do we define success for an accessibility coach? well the coach is responsible for making a self-sufficient team. A team who can build and maintain an accessible product with very little support from an accessibility coach or from the central accessibility team. And once the coach is done they will move on to another agile crew.

 I wanted to set the context because when we were first talking about this problem of creating a self-sufficient team, my biggest concern was the people who write the requirements. We were all around the whiteboard and I said we will never be able to train the people who write the requirements. When you think about the skills needed to create really great accessibility requirements if you think about that venn diagram three big skill sets that you need, the first one is understanding the accessibility API that the platform you're working with him. So if you are on the web understanding HTML, CSS, JavaScript, area spec. Understanding the accessibility of ADM line of the area you are working with in is the first skill set, the second skill set is being able to look at a design you have been given from your designer and understand how to build it out in an accessible way. And the third skill set, and certainly not the least of the skill sets is actually communicating all of those things to your team.

 So when you think about the Venn diagram of the skill sets and how they overlap I have this picture in my head of the population being very very small. In trying to expand the population being a very difficult problem to solve. This is what some people might think of as a unicorn hire. Someone who is a needle in a haystack, very difficult to hire for. And so a lot of what we are going to be presenting today is all about how my team push back on this assertion that we can't do anything about requirements. And we came up with some novel approaches to writing accessibility requirements and I want to share those today.

 So first of all we are going to talk about the why and the who. So why do we care about accessibility requirements and who writes accessibility requirements and then we are going to spend the rest of the presentation talking about the how.

 So why accessibility requirements, why are they important? one of the major tenants at agile is communication. We want to be able to communicate what we want to developers and our testers. Developers need to know what to build and our testing team, the QA need to know what to test. Okay, that is kind of what requirements boil down to and certainly for accessibility requirements that is certainly true too. 

What we found as well is that better requirements also lead to better estimates. And good estimates is a really good thing. It helps the introduction, it helps the inertia accessibility. It helps people just get on with new user stories. Without much fear, uncertainty and doubt, and echoes on to my last point here. 

Having great and clearly written agile accessibility requirements, you are removing a layer of Mistry from accessibility. And this is a really big problem for teams that are new to the subject matter. And so good accessibility requirements really help with communication and they are going to help with the inertia when you approach a new team, a new agile team, and agile team that is new to accessibility. Okay so that is the why.

Let's think about the who. Who writes accessibility requirements. Well at PNC we think it is a team sport. Lots of people in your agile crew are responsible for accessibility requirements. Designers obviously are responsible for creating an accessible design. It is certainly true you can design something that is very hard or impossible to make accessible. So designers have a role to play saying we are content writers. Content writers need to be able to produce clear and useful content that will improve usability and in specific cases there are specific things content advisers need to do for accessibility and so they have a role to play in the think a lot is written about the role of designers and the role of content writers. But less is written about other roles. So how product owners, scrum masters and rules like a business system analyst. 

Now a business system analyst at PNC that's not a job title we have at PNC.The title doesn't matter. The roles and responsibilities do. For us, the BSAs, the business system analysts, those are the people responsible for writing the requirements. Within your organization it might be the product owner. It might be somebody else on your team. Like I say, don't worry so much about job titles. Think about roles and responsibilities. And we are going to drill into the role of the BSA today and how you know, for the folks... For the folks who are responsible for writing requirements, how they can write effective accessibility requirements. All right so we have covered the why.

 We want to communicate, we want to communicate to developers what it is they need to build.We want to communicate to testers what it is they need to test. Let's think about the how. All right, so there's a couple of kind of recommended techniques toward capturing accessibility requirements. One I think is really documented within the accessibility community and that is annotate and design or annotate wireframe. If you are not familiar with the concept I have an example here. Here I'm showing a wireframe of a web browser containing a webpage. There's a heading at the top followed by a data table. 

On top of this design we have  a selection of notes, which are annotating the design putting two different aspects of the design and calling out specific accessibility requirements.

 So for example we have one annotation that is pointing to the heading and it is saying the name, role, and value of, name and role. I'm sorry, that particular heading so the name is Bill pay, payment history. The role is heading, the level is one and it has even got some recommendations in terms of how you develop this. So are using H one in this case, and there's several examples of annotations in this example.

The point with annotated designs is that they are really cool in that they show requirements, accessibility requirements in situ. If you are a and you are looking at the design your accessibility requirements are right there and that is really useful.

 Our thesis  is that this only solves for half the problem. Design limitations at least in this format that I'm showing do a really great job of medicating to developers what it is the need to build. But when it comes to testing to what it is they need to test, so how do you solve for that? when it comes to our second recommendation here of using user centric design specific requirements written in the gherkin style. So this is given when then style this is the idea when many use cases become very popular within agile teams. We are going to look at the style of writing requirements and a lot more detail. 

Okay so how does PNC do it? how'd we write our requirements how do we write user stories within an agile Sprint? the first thing we do is for every user interface we actually break it into two. We have a functional user story where all the functional requirements for the user interface component are captured and we have a separate accessibility user story. And the key thing is that they come as a pair. They go into the same Sprint and the worktime at the same time so the pair of stories, the breakdown we think is very useful. The reason we think is very useful is that it helps with estimation in our experience and really helps with estimation if you break out the accessibility requirements. And then when thin both of those stories we document acceptance criteria which I will refer to as ACs for the rest of this presentation we document ACs in the gherkin style, the given then when style.

This style is very popular and easy to read. A given statement is meant to describe the context. The win is describing that user action and the then statement is describing what you expect to happen. So here is an example of a gherkin style acceptance criteria for accessibility.

It starts with a scenario. And the scenario is a little summary of the AC that you are describing. And it says a sided keyboard only user with a motor disability can operate with the interface by only using a keyboard. Then it goes on to say given I am a sighted keyboard only user with a motor disability when I navigate the page with a tab key forwards and backwards then all interactive objects receive focus and all interactive objects are operable and all interactive objects receive focus in a logical order and I can always visually tell what element has focus.

 So in the six lines of gherkin, the sort of six line many use cases there I have managedto capture quite a lot of WCAG success criteria. So that is just one example. We are going to dive into lots more today.

Now what I want to do is first to take a quick reality check. So I have suggested that these user centric design specific requirements are really a good way of capturing accessibility requirements. But when you are doing this at scale you're going to start to run into some pretty big problems pretty quickly.

 The first is verbosity. It is just human nature, the more, the longer requirements document the less likely it is that your audience will read it. So with any kind of requirements, but especially accessibility requirements you have always got this trade-off between verbosity and clarity. You can choose to be very verbose and very clear but then you are increasing the chances that no one is going to read it. Or you can choose to be succinct, and compromise on clarity and the trade-off is that you have an output that is not exactly what you want, so verbosity is a problem.

 Consistency is also a problem. If you have a lot of accessibility characters across all the agile crews you want your  coaches to be calling the same requirement the same way across all your teams. That consistency is a big problem.

 And then finally our  unicorn reappears, the expertise problem is still there. You still need a lot of expertise to be able to write these requirements. So what can we do about that? how can we solve some of these problems? 

well at PNC we solve this with a component library. And when I refer to a component library I am really talking about two things at this stage. I'm talking about a design system, so a set of design standards which document how a user interface should be built at PNC. Kind of all of the symbols needed to create a user interface and how to use the symbols in order to create a webpage or create a mobile app.

Now the design system is like the pictures and the words, where the component library is the actual code needed to create that design.

 So to give it a formal definition the component library is a reusable set of interface components that can be consumed by different agile teams within your organization.

Now why is this good for accessibility requirements? there's lots and lots of reasons. I would argue it's actually good for software development in general right? if you are building once and reusing lots of times that is good software development. It's really good for accessibility because it means you have got one team you can really nail the accessibility requirements for your components. And that all of that great work can be shared amongst many teams. It also makes your suite of products more maintainable because if they are all using a component library as soon as you add more accessibility features or you fixb consumer teams are going to get the features for free. Also if every team is not reinventing the wheel, then and using your component library they are moving faster and will deliver to market faster and that is great software development practice and also good for accessibility. Accessibility is not slowing things down. That's often a very popular myth when we talk about accessibility. And related to accessibility.

 All of these things add up. Every team who is using your component libraryis saving a bunch of money by not reinventing the work. You are having more consistent experience across the component suite and the experience is accessible also.

 Some good examples of component libraries, a coupleof component libraries I really like, shopify Polaris, and Zurb's foundation is another one. Both of them do a good job documenting their components and incorporating accessibility requirements into the documentation. So they explained to developers very clearly how to use the API to create an accessible experience. And I think that's actually a really good sniff test. When, if you are considering using a component library within your own set of products, maybe you are looking at an open source one, looking out for good accessibility documentation within the component library is a really good first sign.

 If a component library has the documentation that is a good indication you might want to invest moreto test out the library and really make sure that it is accessible and something that fits your requirements.

So let's have another reality check and see where we are now that we have a design system and component library. What impact does it have on the requirements and the ease at which we can develop good accessibility requirements.

 Well it makes all three problems identified a lot smaller , they are still there. It doesn't solve for every problem, but it makes the scope of the problem a lot smaller. So the impact on verbosity... Well if you are making the assumption that your teams, your agile crews are using a component library then you can assume that a lot of requirement, you know how a particular component in your design has been built. So you know that a whole bunch of requirements are kind of codified into your component library so if they capture the component library and the team is using the component library you do not need to writer So that helps with verbosity.

The second thing is consistency. If the verbosity problem got smaller the consistency problem got smaller too. Less chance for inconsistency. And also the other... The other point on consistency is if you know each team is using the component library you know and using it consistently you know the text build in one product is the same text build in another product in the behavior is going to be the same so that also helps with the consistency problem. And finally expertise. Again a lot of the expertise required to build accessible components or accessible requirements, sorry, is baked into your components within your component library. So that is great. Again, less requirements to write and less expertise that we need in order to think through all of the kind of super set of requirements.

 So you might be looking at this component library thing. The design system and say hey, Ben, this is great, component libraries are great. But why do I need to worry about accessibility requirements? doesn't the component library take care of everything? well, in our experience, no. Accessibility requirements are still very much needed. A component library can take you a long way. But it does not solve every problem. It's not a silver bullet.

 So the first thing that accessibility requirements can help you with is human error. Somebody might take that text input component that you have lovingly crafted and put a really terrible label on it. Somebody might take the image component and provide horrible alt text, and so the accessibility requirements can help you guard against poor implementation of your components within the library.

 The second point is that accessible building blocks don't guarantee an accessible house.So what I mean by that is that there are certain page level requirements that you need to consider. So you can put all of our accessible components together to form a page, but that still does not cover all of the WCAG  success criteria there are things like page titles and linkage of the page, language of parts. Keyboard focus and keyboard management. Those are kind of page level requirements that your accessibility requirements can capture and help support your component library.

 The other thing to say as well is at scale when you're working with enough agile crews , your component library is not going to cover everything. Oftentimes designers will hit novel design problems and they require novel solutions. That might not be in your component library. And teams should be encouraged to work on those solutions if they are the right tool for the job. When you do that you need to make sure you have got good accessibility requirements.

 So really the sort of tagteam between the design system, the component libraryand accessibility requirements really helps. And that is really the path forward we use at PNC. Okay. So the kind of third part, the third leg of the story if you like, we have a design system we have a component library, then we have an AC library, the acceptance criteria library or to give it the full name, the accessibility acceptance criteria library. The AC library.

 The easiest way for me to talk about this is just to demo it.So I'm going to go over to my keyboard now and start to give you a quick demo of the AC library and how the AC library is going to help teams who use the component library write good requirements.

 Now here is the AC library. It has three sections. We have a welcome section. Within the welcome section we talk to people about how to use the site properly. How to use the tool properly, the workflow for creating requirements. We talk about how you can contribute to the AC library and we talk about places you can go for help and to give feedback.

That is section 1. Section number two is AC for BSAs. BSA are the primary audience for this tool, for this documentation. Within the AC for BSA section we look at two things. Universal AC and component library AC. So let me take a deep dive into these just real quick. Universal AC, AC that should appear in every user story, every accessibility user story. There are two here that we use. All the time. Axe expert and keyboard. So Axe expert is making sure that they products are clean and there's no violations in the pages we are creating, the second universal AC is keyboard and actually we read it in our first example. This is making sure that all the pages we create are keyboard accessible. So that is the universal AC section.

 We also have a section for the component library AC.So what is that all about?

well if we can make the assumption that you are using the component library, then we can write just enough accessibility requirements to make sure that you are using the components correctly okay. In other words every component in our component library has a set of matching requirements in the AC library. If I go to the text input for example you will see what is going on here. We have a screenshot at the top. We have some design and content considerations. This is not a set of requirements. It's really just a list which our BSAs can use when they are talking to designers and content teams. But here are the AC themselves. And the AC, this section has a bunch of instructions so in this case it says to use the universal AC, make sure those are in your requirements. And then use this custom AC for this component. Text input, screen reader user experience. If I go to that page then you see the given when then statements, these scenarios.

In the makeup of this page we have a scenario at the top given when then AC is going to go into requirements. We have suggestions and the suggestions are really implementation suggestions and most of them are saying use the component library. In the section at the bottom here is further reading. And a lot of the links, what they are focused on is helping our testing team QA read up on the testing methodology for this particular acceptance criteria. And a lot of these links go to Deque University which is a tool we get a lot of value out of. So that is a very quick deep dive into the AC for BSAs section. We also have a third section, which is AC for coaches.

 So coaches that is a reference to our accessibility coaches parts of this is kind of more of a prouser section. We have WCAG accessibility requirements written for WCAG success criteria and those are good way of capturing AC for accessibility bugs related to different WCAG SC. And we have a section for generic patterns. And so with generic patterns the starts to answer the question what happens if you are working with a team that is not using the component library. In that case we need to document a different set of requirements because we no longer make any assumptions of how we have implemented a component. So if you go into any one of these generic patterns there's going to be a lot more requirements to consider. Okay cool. So that is the AC library. A couple of other things as well in the AC library it supports fulltext search and you can also download it and use it off-line which is kind of a nice feature. I want to keep moving forward. So how do we teach people how to use the AC library. While we have this process called the DCAG process which is a play on acronyms and a hat tip to WCAG and D stands for review design, C is for identify components. A is for identifying a C and G is for reviewing gaps.

 And I'm going to have a go at trying to demo this process to you now.And hope you understand how we go build out requirements at PNC. What I am showing on the screen right now is a design, it is a design showing an account opening process for the virtual work checking p headings in different form fields and buttons and things like that. The first step is in the DCAG process is designed what we train the BSA to do is have good conversations with designers and there's a handful of questions. Things like asking for the mobile version of the design and the desktop version of the design that has an impact on accessibility requirements. It is things like asking for hover states and focus states for the interactive elements within the page. That has an impact on accessibility requirements. Other things are things like did you consider color contrast of all the elements in the design. The idea is that BSA wants a more accessible design from the designer. So they have the discussion with a designer hopefully they get a more accessible design back. That is the idea. That is step one on the design. Step two is identifying components. In this step, what the BSA will do is and they review the design and player matching game matching the designed components within the component library. And when they find a match they are writing that down on the design and annotating the design to spell out the match. Let me show you what that looks like when you go through that process.

 So in this screen now I'm showing the same design but it is annotated. There are a lot of components called out. Things I have matched up in my component library and some things that are not in my component library I have identified as gaps. Okay so that is the C step is is playing the game is looking at the design and matching to the component library.

 The third step is identifying AC. So this is the second matching in. I look at the design annotations so select menu text input phone input are some of the examples in the design right now. And I go to the AC library and I find the matching requirement so let's do that right now.

 So the first one was the select menu.So I'm going to go to the component library and I'm going to go to the select menu. And follow the instructions. Said include the universal AC. So I'm going to do that and go here and copy the scenario and add it to my requirements document. And I'm going to keep repeating the process so I'm going to go through the instructions and it says include the other and I'm going to include the other AC and I'm going to put it into my requirements document. And so I'm going to keep going with the process. There's an AC for the select element this case it is the screen reader user experience. I copy that scenario and add that to my requirements document.

 So that is my first component done.

Next up is the select menu. So the second component is the text input and actually I can see there's a couple of text inputs here so I'm going to do with both at the same time. So I'm going to go back to the component library and find the text input. The I'm going to follow the instructions and include the universal AC. I have got the component so I don't need those can but there's another screen reader experience AC for text inputs I'm going to copy that scenario and add it to my requirements. There's two same types of the same components I'm going to add the second component, the second instance of that component to my When Klaus and I want to be able to differentiate the two of them so what I will do is add the label I'm going to the first one is called employer and I'm going to put the placeholder text here and the second one is called start date so I will throw the label for start date into my requirements. I have got some more refinement to do here. I can see there's placeholder text here. On this one is called occupation and so I'm going to add occupation there. Other bit of refinement that I need to do is that each of these has got space for a number and this is nice to have and it lets us refer to each AC by. And so I'm going to go through my AC and start numbering them. And so one, two, three, four etc. I'm not going to go through the whole design I just want to illustrate kind of how we used all the tools together. So hopefully this gives you an idea of how we use the component library and AC library to write good really good accessibility requirements fast.

So we got through DCA within the DCAG process and we are now on 2G. What happens then? When we get to G we train the teams on how to ask for help. This is a great time to raise your hand and ask for help. So we tell the BSA teams okay if you are looking at a component that is not within you are component library this is a great time to work with your coach or work with the central accessibility team, or sharpen accessibility office hourst And we will help you write requirements for that component. That is the DCAG process design components AC and gaps. And once you fill the gaps you have got the complete requirements document, and that can go into your accessibility user story.

I'm going to keep moving forward here. Just a big comment on the bigger picture hopefully we have been able to illustrate today these three tools, design system component library and AC library can have a powerful impact on your BSAs and BSA training. But if you look at the tools really they have an impact on your program as a whole. You can reduce the amount of training to all of the roles need within your agile crew. You can get your team up and running much more quickly. They want to become accessibility experts just because they are using the free tools. Obviously you need more advanced training for that. But you can start to create some really excellent products from the accessibility point of view very quickly by using these tools. You're certainly giving your team a great head start. So let's look at the impact by role. So designers, they can use the design standards and the design system. That is going to get them up and running much faster. Requirements writers, BSAs in our case can focus on using the component library and the AC library and follow the DCAG process that we just went through and they're going to be up and running a lot faster. Developers, we can customize the developer training if we know that those developers are going to be using the component library. So we can train them to use the component library and train them to read AC coming from the AC library. The same thing goes with the testing team, quality assurance. We can train them to read and execute the AC that will come in from the AC library. Also our experts benefit is also the accessibility coaching to get a lot of value from these tools. On boarding a new coach. They have WCAG expertise awesome. But they need to know how PNC does things and by having these tools I can get up to speed very quickly. And across all of our roles we try to be consistent about how we get people asking for help and how we approach advanced training. If you need something really custom that is not in the component library we can have the conversation in a very focused way. We don't need to worry about things that are already documented within the component library. 

All right we are getting to a wrap here. So I just wanted to summarize, the combination of these three tools are designed system, component library and AC library can help you write accessibility requirements quickly, specifically and consistently. Good accessibility requirements will mean better products with fewer bugs. You can be more focused when running your accessibility training too. And that is huge, training is expensive.

And finally you can get your team creating accessible products more quickly. You are making your team more efficient. And so these tools are really hopefully we have conveyed how powerful these tools can be. If you are interested in learning more about effective techniques to capture accessibility within an agile process I really recommend Dylan barrels of book accessibility explained, it's a book that me and my team enjoy it's got a lot of the features that we mention today are spelled out more in the book things like matching and component libraries and a lot more so that is a book I would recommend. Finally, final thought, this year is a big year for the accessibility team at PNC. We will be doing a lot of hiring this year for accessibility coaches. We have got to open positions right now. One of them we need more applicants were. If you really know mobile applications well, if you know accessibility apps go to PNC.com, go to the careers page search for accessibility and you will find a job there and it's going to be a lot more hiring in the accessibility space at P and say throughout 2021 so please reach out if you are interested. All right. So with that, Ali, I am done and I'm ready for questions.

Ali: all right great, Ben thank you very much, and the first question that came up is PNC accessibility library available to the public and if not, are there any AC libraries available?

Ben: you know what, that is such a great question. So yes, PNC's accessibility acceptance criteria library is not available to the general public. It is proprietary to PNC. One of the reasons we wanted to give this presentation was to inspire others to create something similar. And perhaps an open source version. In our research we really did not find anything that was similar to what we ended up creating. Yeah. Nothing really similar. Not in documentation within W AI. Not in another component library. We just have not seen anything similar. If anyone knows of anything similar we would be really interested to take a look at it and compare and contrast with the icy library. Sadly know the PNC of version of this tool is not available publicly. I'm unaware of any other public AC libraries. But if anyone else is aware I would love to know

Ali: next question with the accessibility coach model how do you --- to keep accessibility skills in place.

Ben: Wow. That is cutting to the heart of the matter. That's a great question. Turn over or team churn is almost like the Achilles' heel of the coaching model. It is heartbreaking to invest a lot of time into a particular role within an agile crew only for the team member to walk out of the door. But I think that probably goes for any skill set. If you have a valuable front-end developer and they walk out of the door that has an impact. What you need to do is create an environment to make sure that the impact is reduced. So how do you get from gap to know gap as quickly as possible and I think some of the tools we have presented today really help with that. Because if you are using, if you are not re-creating things from scratch and you are using component library and you're using these other tools you're standing on the shoulders of giants already and that is kind of a better place to start from. I think it is a great question that we are still working through. In terms of how do you make sure, how do you reduce the impact of team churn. Great question, I was not sure that I've got I think some of the questions we have presented today really do help, but the way we view it is how do we reduce the impact and yes I think we are still working on the problem too.

Ali: Right. Next question that came in in your post Sprint analysis in examples  cited were--- point insights etc. what impacts have you seen from having separate accessibility user stories. This seems to break agile best practices a bit so I'm wondering what the effects you have seen.

Ben: yeah, so I don't have any hard metrics kind of to share today. One of the things we do measure is we measure how many stories, how many accessibility stories go through every teams backlogs. We use [Gira] to track that and we are obsessed actually with accessibility coach is getting traction and making sure they are able to get traction and making sure they are able to see accessibility requirements for not only getting into the backlog but getting it done. I guess the only way I can answer the question is that it works for us. I think in terms of agile best practices yes I think you are right. There is I guess some debate in terms of the idea of false life stories we put everything for a particular UI screen in the story, so front-end, backend, everything you need goes into the one story and you know that once you take the requirement to done the feature really is kind of done. But then I think there's also the other I think another school of thought that says hey, you want to break down your stories into more consumable chunks. And so I think there is a trade-off and it is whatever works for your team.

 One of the things I will say is that we have a practice of separatingout functional requirements from accessibility requirements to begin with if you are a new team it. But as you get more confident with accessibility, as you are more mature in your accessibility journey we recommend you put the requirements back together and you can deal with one story. The other thing that I would share as well is... We did not just create this for sort of the fun of it. One of the reasons we created these AC library and the whole approach was that we started out trying to put all the accessibility requirements, we tried several different ways of writing the requirements and putting them in the functional user interface story. Basically in this either full flight story or a front-end story. And it didn't work. We did not get any traction at all. And some of the feedback we were getting was this kind of people were so like scared of the subject matter, there was an empathy gap, there was a skills gap. So we have to get creative about filling the gap and making accessibility more consumable. And we came up with this approach like I say that now works for us. We do get good traction with our accessibility requirements and we are doing a great job of getting those requirements done.

Ali: we have got about five minutes left so I will try to get in as many questions as we can. The next one is if you break stories into functional and accessibility categories what of the functionality have to be retested once accessibility is implemented or vice versa based on which comes later?

Ben: Yeah, I mean that is a great question. That's a great question. What we would recommend is typically that the pair of stories is worked on by the same developer. So while they are kind of logically separated when it actually comes to actually doing the work the same developer is working on the stories at the same time so I think initially that downside might actually be a reality. You might be pushing through the functional story first and then kind of remediating that functional story that you just pushed through to done. Remediating for accessibility in the same Sprint and moving the accessibility story to done too.

 In our experience you only make that experience once or twice before you start working on that storyor those two stories at the same time. So like I say there might be this logical separation but kind of if you are smart about the way you do the assignments on the stories re-factoring remediation kind of in Sprint becomes less of a problem.

Ali: Okay. I think we have times for two more questions. The first one is what percentage of developers or testers who know how to use a screen reader at PNC?

  

  

Ben: Yeah. So we train every team every dev team and QA team that comes through the coaching program one of the elements of training incorporates screen readers. Yeah. And we train folks on how to use NVDA. That is kind of our focus. And we have had a lot of good results. Yeah. I mean one of the things we have done is we have kind of gotNVDA set up so it's a one-button install which pre-configuration so it is set up well and works on the QA laptop and NVDA doesn't take over too much and it's kind of we call it the testing configuration for NVDA. And everyone gets a training. I'm sure that when the rubber hits the road within an agile crew there might be some sort of specialists like within the team who feel more comfortable kind of testing with NVDA or testing as a developer or a member of the QA team. But our expectation is that developers are certain exposed to it in training and they should be using it as they are doing testing. The other thing that was interesting when... A story I will quickly share is when we started our journey of training we wanted to stay as far away from screen readers as possible just because we felt like it was intimidating and hard and difficult to teach. But what we found in practice was when we started giving feedback to developers in QA and saying hey we found some bugs it doesn't work in a screen reader, they just started picking up screen readers themselves. And what we then found was it was much more dangerous for them to be teaching themselves how to use the screen reader than it was for us to start taking training seriously. With screen readers. So then we took over training and all of our devs and QA should be using the screen reader.

Ali: And unfortunately we are at time and apologies that we did not get to all the questions but I want to give a special thank you to Ben Allen for a great session and thank you to everyone for attending. Enjoy the rest of the Axe Con and we will see you soon.