Type: Breakout

Track: Development

Linters are amazing tools to find basic problems in source code. With axe-linter, you can test JSX, Vue, Markdown and more all at once, without long build steps, or even having to open a browser.

 

>> Okay.  We're almost that time.  Welcome, everybody who has just joining us.  My name is Liz.  I'm from Deque.  Let me go over housekeeping and pass it off to our presenter Wilco and Michael.  We have a got of questions rolling in, guys.  This is early for questions.  Awesome.

Okay, we are at time.  Hi, everybody.  Welcome.  If you're an early bird you said me say welcome a hundred times.  Thank you for joining today's session.  If you're looking Axe-linter test in your editor brought to you by Wilco Fiers and mic Michael.  I'll turn it over to Wilco to get us  going.  Today's session is recorded.  And hosted on demand.

If you do require captions there should be captions right below this video stream.  And finally, as I said, questions are rolling in.  But we'll reserve about ten minutes for Q&A and get through as many questions as we can at the end of today's session.

So with that, I will turn it over to Wilco to get us going.

>> Thank you, Liz.  Awesome.  I'll see if I can try a little bit more time for questions.  It sounds like we might have a lot of them.  I'll give it a try.

All right.  So let's start Axe-linter testing your editor.   So firstly, my name is Wilco Fiers.  Had he him, my  pronouns.  I'm a developer and product owner of reasonable accommodations score in the new Axe-linter.  In case you're wondering where there's a -- in the first slide and not in the second slide.  I don't really know yet.  The marketing team has been super busy.

I'm the facilitator of the ACT task force which seeks to hom anize accessibility test to go resolve inconsistencies between tools, accessibility, auditors and that kind of stuff.  And I'm also the Co-Chair of the ACT rules community group which is focused on a-- I'm a member of the silver task force which is a group that works on WCAG 3.  And with me today is my colleague, Michael.

>> Thank you.  So my name is Michael, is eik.  My prowrnlingses are he him.  I developed Deller Axe-linter and axe define tools for testing.  And I maintain and develop axe core NPM integration.  If you stop by GitHub, you go see some of the work over there.

 

 

>> Awesome.  All right.  So linter.  What is it?  Firstly, I hear we have a listener from Belgium.  So you might know linter Belgium.  It's a lovely little place, somewhere in the middle north of it, Belgium in the province called  south-- which is strange because it's in the north of Belgium.  But not just strange when you think there's a north-- which is in the south of the Netherlands.

So that's linter.  That's what we're talking about today.  I would recommend you go there if you have a chance.

There's also cotton linter which I found out is fibers  peeled off of cotton seeds after ginning.  It's referred to as cotton wool.  Used a lot.  It's another kind of linter.   The kind we're talking about today is the software.

And software linters kind of got their start in the 70s or so.  And is they're used to do code analysis.  Static code analysis.  It's a tool for static code analysis.  What they do is add additional checks for bad design, bad codes, things that look wrong but may not necessarily cause a compiler to fail.  And they're especially useful in  languages like JavaScript which is a typed language, or let's you do anything.

Um, that on a function, hello world with a variable message, that has no body in it.  It will-- the values never read.   That's nice and useful to tell you you did a thing.  It doesn't look like you completed your work.  And by using linters, you get cleaner code.  You get stricter code.   There's less of why is this weird thing happening here?   Going on if you properly use a linter.  Another thing  linters are used commonly is dealing with white space.  Tabs versus spaces, discussion.  If you want that happening consistent, you can use linter.  There are linters that fix this for you.  The so common linters, um, in the JavaScript ecosystem, it's pretty much the go to at the moment.   There's also TS lint which is for type script.  It hasn't been deprecated.  If you are still using TS lint, switch back to ES limit.  It will work better for you.

PY lint is another one.  Check style is in Java.  And there is super linter which is an interesting one.  It's a linter developed by Microsoft.  And what it does it works in GitHub actions and it actually runs various linter.  It returns a bunch of different linters on a bunch of different source files.  All you have to do is set it up that's why it's called super linter because it limits lots of different things.  That's what a linter is.  There are a number of linters out there for testing accessibility issues as well.   There is precedence in here.

Last year, now, I believe a little bit over.  I think it was December 2019.  Deque released a GitHub app that we called  Axe-linter.  This is maybe the first thing people have some familiarity with.  This was essentially a proof of concept for us to show, hey, is this linting thing useful?  If we build a thing, will people use it?  Um, and how would it work?  So what we did there is we did the GitHub app that used some out of the box linters to do things for us.  What we are releasing soon is our very own linter.  No more this out of the box linting system.  Some of the accessibility this thing out there, the post popular is JSX A11Y, it's a mouthful.  JSX Ally which is a plug in for ES lint which helps you test, for common accessibility problems.  It the one of the most popular.  One of the most downloaded accessibility tools out there.  It systems standard with create act, if you're using axe create --

There's Vue Ally.  There's also web paint which is a product developed by Microsoft which I believe available in various ways.  You can use it as a plug in for VS code, for example, and it will heft HTML there.  Kind of interesting, web paint actually uses axe core in the background.  If you have web paint already, you are secretly using axe core as a Lynner it.

And maybe a linter, not quite a linter is Svelt.  It's a JavaScript framework.  It has, when you compile, it will tell you if there's accessibility problems.  It's unique in in that approach.  It the really cool.  I want to highlight this.  I think accessibility moves forward with projects like this where accessibility is built directly into the tool.  If you don't want it, you have to turn it of 0 rather than a thing you install.

But when dealing with linters, there is a lot of challenges.   Linting for accessibility is complicated than automated accessibility existing in a browser.  And before going into Alily I want to show the challenges you get one building a linter.

So I want to go through some of the the examples.

My first one is incleat DOM trees which you get when with development, you use templates.  You may use components.   And so you have a small file with some piece of HTML in it that has, will be embedded should where else in the page.   This is on my screen is a template element with a UL and LI element inside of them.  This is a few component, few users templates at the root.  And inside of that UL as aible ising to the LI, there's a slot-- with a name of list.  And this slot element can be used to place various things in it.  You can put other other elements in it, or tables in it if you want to or buttons or whatever.  When dealing are a linter, this code can about any where in the page.  That is something linter will account for.  And it has to account that slot can be empty or can have lots of different things.

So there's lots of unknowns in dealing with this.

Similar pro be happens with attributes.  I'm showing a code snippet of how it reacts using JSX.  And where there's a mine input component, and props which reacts for attribute and this my input component inputs elements with a dynamic type.  A type is-- if you're using my input you can declare it to be anything.  So, when you're writing a linter, it -- you're not going to know what is happening here.

So it's hard to tell based on this, what that type of can  be.  It could be on the define-- this code does not require that it be a type.  It could be a no attribute.  The other thing with linters is attribute spreading.  In react, in  JSX, you can see in the dot, dot, dot misc here, the way they use it, what it means anything on had misc as an attribute to my input element.  Linters would not even know if there's an ARIA label attribute in this thing if it's disabled in some way.  There is lots of unknowns about this.

There are also components to deal with.  On my screen is a Div that is a text field.  Sorry.  Let me start that again.   Theres a text field component as being declared with the outer element is a Div.  And inside of there is a cool label component with the name label attribute and next to it is afternoon input element of typed text.  This cool label could very well be a label of this input element.  Because it isn't using a native label element, it's hard to know for sure.  There are lots of unknowns in components, too.

And lastly there's no style that's happening.  If you have a button with the well known SR link which is shorthand for only screen reader, this information, because you're testing the source code and not inside of the actual browser, it is not known to a linter read or not.  This text is going to be rendered.

A little bonus, there are in templates lots of conditions.  On my screen is a few template, inside of it a button inside a span with a V-if directive.  The V-if directive is what it let's you is optionally hide.  If the V is true, it will show the element.  If false it will hide it.  This bought ton element may or may not contain a contents.  What do you do as a linter?  If you flag this as a problem, it will fail this button even though that condition may always be true.

There's a i are of false positives in lots of ways that don't exist when testing a normal.  Everything is rendered.   All of the information is available.  Note

Which brings me to Axe-linter.  Axe-linter this new iteration that we are doing is a tool that has, is fully consistent with axe core.  This is one of our first principles that we wanted to adopt when we write, when we want to write a linter.  We need to to be exactly the same as axe core so that, if you have a problem in axe core, you'll also see it in the linter and vice versa.

We do not want due to these minor discrepancies it's important to us the tool you have is reliable and  consistent.  Ax core does that with a heavily relying on the way axe core does thing.  We want falls positives in Axe-linter.  This is not something we can always guarantee.   False positives are bugs, and bunkings are in the software, but if you report it same as axe core, in Axe-linter, we will fix this.

One of the more exciting about Axe-linter to me is that it supports multiple languages.  The linters we've looked at before, Ally, web pains, they only target one specific language and they do it in their own unique way.  The so testing one versus the other is going to be causing consistencies if you're using, for example, if you're using lighthouse or X extension, there is going to be  consistencies between what your linter does and what you get from your extension by supporting multiple languages we ensure that whatever you're using is going to be the same.

So currently, what we'll be releasing with is support for HTML, JSX, TSX, mark down, and vue.  T.  Is X is touch variant-- react essentially.  *

And then what we are also building for -- these are still fairly early is a better understanding of the logic.  It's a conditional logic of your code.  So that, the statement I mentioned before, we want Axe-linter to know what's going out there and give you smart feedback about that.

And another somewhat experimental feature, a feature that my be unique to Axe-linter is the ability to suggest fixes.   This again is still in its early phases.  We have some evident its with JSX to get this working.  And we will be working to expand this to other languages as well.  Really we want to be able to have Axe-linter work in essentially the same way as spelling checker works.  For me that's been a dream that I've been working towards for the last three years.  Accessibility really should work in a lot of ways the same way that a spell checker, woulds.  A little underlying as you write your code, * click on it, it gives you a little pop-up.  It suckings a couple of options, you click the one that's right, done.

As for where you will be able to get Axe-linter, we are releasing Axe-linter in two variants.  There will be Axe-linter in code editors.  We are planning to release an extension for visual studio code this month.  And we are working on Intel J IDEA and web storm as well.  Um, then once you have your code and all done and you're ready to system your code what we have is to have Axe-linter available in request as well.  I mentioned of before we had a proof of concept for GitHub apps and we are releasing Axe-linter in the GitHub app soon.  And we are working at other, on other systems as well, what those might be will be a little bit more later.

For our rules, it probably won't surprise you that we don't have the entire rule set ready to go.  This will be an evolving and moving target.  But what we're releasing with this month are the accessible name rules.  The image ALT, button name, frame title, those kinds of common rules.  And then in addition to that event handler rules, rules like click events has key events, if you want all of the things you do to have a corresponding keyboard accessibility.  Know interactive static role.  If you have an event handler on the static elements that can create a lot of problems.

You want things that can take focus that take events on most events to be focused and to have a role.  Those are going to be available right away.  And currently in had development are what I call attribute rules.  Those are rules that look at specific attributesment there's things like ARIA allowed ATTR which is a rule that checks that the ARIA you're using is allowed on the role or element.  A valid Lange.  Auto complete valid.  Checks auto complete valid.

And can then a little bit further down the line is the parent/child rules, things like checking label.  The contempt of a label and the accessible name mismatch if you have a button and an ARIA attribute, you want those to be consistent.

Rules checking that ARIA required children are present.  If you have a box as an example, that requires a text field and I believe one of a number of components like list, those kinds of rules are coming later on.

So I talked about Axe-linter.  Understanding your language.   My screen are four code snippets the first one is JSX attribute spread where I'm showing how Axe-linter, when there is an image with a source attribute, nothing  happening.  Will flag that element.  But if there's a source attribute and there's attribute spread in JSX, notice element-- that's a attribute sprealdz might include an ALT attribute.

Who this is a few components.  A template element and two buttons inside of it.  Both buttons are empty.  One is the first as an issue and ignores the second because it uses the V text.Ed V text let's you put text inside of an element.

So you'll see here, V text is a view specific thing.  And because Axe-linter understands.  Have ue, it knows what to do here:  Because Axe-linter knows JSX, it knows what this attribute spread means and it knows to ignore it.  This is different from how some more generic-- work, where they have a loose kind of parsing that's happening.  And they make lots of assumptions about the content.  But because Axe-linter understands the language that you're working in, they'll only flag things that are actual accessibility problems.

The next two examples on the screen are two HTML documents one there are there's an HTML element and an input element inside of that and another with a Div and an input element inside of this.  Because Axe-linter understands if you have an HTML element at the top, this is a complete page.  Are input element must have accessibility.  So we are underlining that.  For the Div if you have a HTML file that starts with a Div, it does not require this input element to have an accessibility name because this template may very well be placed inside of a label.

If this template is nested inside of a label element, there may not be a problem.  So understanding the context of the language is very important in why in a lot of cases Axe-linter may not always get quite the thing you want from it.  But it will be very careful to invoke false positives.

So by this point you probably want to see Axe-linter happening.  And that is why Michael is here.  So Michael, tell us what you're going to be doing.

>> Will I'll show you guys what I'll be demoing.

So I am going to be demoing our VS code Axe-linter and GitHub plug in and GitHub app as well.  In front of me is a tight script react project.  Just a basic react project in  VS code.  So in this instance we would install it from the -- when it's out it will be in the marketplace just like any other extension.  So I'll install it on the bottom right you will see it is setting up and fetching the local server.   What will happen is a two step install.  The first installed Accenture and the next install the -- utilize the linter aspect of it.

In the extension it eleven is, you can see that it's a page just like any other extension page with fairly good information since it will show you an overviewpt of what accenture does and also ability to make any additional changes that you may want if you are trying to add specific rules or utilize specific rules disable specific rules this page will help you out with that.  You can also disable specific tags to specific level.  If there are support you need, you can open up the issues in our axe core issue page or different page or feel free to join us on our axe  channel.  We will get into the demo of the Axe-linter.

In demo we will be adding an image to this component.  The image will be of this corgy that is sad when your web page is unaccessible.  I'm going to add an image tag now with a source of corgy image.  And I'm going to close the tag without adding a ALT attribute.  And immediately you can see that the one code is under lined in red.  If you highlight it, you can see that Axe-linter is telling you that you should ensure that the image has an alternative text.  But also a help link to actually see more information on the left-hand side you can see that the file actually changed to red to denote that there is an issue on that page.

 

 

And on the bottom, where your terminal problems and outputs are on VS code, it will show that same information.  And a help URL to actually open up and go to our university page to get more information and why this is an actual issue.

So back to VS code.  The way to fix this is to ad an ALT text.  And ones you add an ALT text, you can see the issue halls been resolved and the code is no longer underlined.  Since we try to stay consistent with our products in Axe-linter, you can see the image is displayed here.  And on the right-hand side if you haven't used it he will feel FreeThink to download on the axe extension, axe Dev tools.   And I'll see if there are accessibility on this page.

It's because it's a scrollable.  Okay.  Live demos is great.   The but this as a spellable content due to the image size.   But once the image has been fixed, it should make it so there are no disability issues.  So once we go back to our code editor we also have testing.  We have unit testing in our package file if you are used to writing a node, you know you can add scripts.  In here we have a test script to run a mocha test and this goes to our index file in our tester.

And in there is actually a brand new package that isn't out yet.  And it is our axe playwright integration.  And it's very similar to our other integrations.  And all you have to do is run that test script which would open up a playwright page to scan the image to see if there are any accessibility issues and we check if the link is zero, and it is.  So there are no accessibility issues at this point with playwright and what we're going to do is now add everything to GitHub.  And now we're just going to push everything to GitHub and I can now show you a full request.  And on  GitHub, I'm going to open the request, create a request, and then you can see our GitHub app.  And it looks like I missed the issue.  So if we go back to our VS code, IDE, you can see that there was an actual disability issue here I had in order so we shouldn't skip headings we can't go from an H1 to an H3.  If I remove that, add everything-- fix.  And you can see that it is no longer an issue.  We no longer have any accessibility issues here.  If you want more  information, you can go to the checks page and look at how many files you scanned if there were any accessibility issues and linting errors.  And for context if there were accessibility issues it would tell you that there are accessibility issue here and that it's failing.  And in the details page or checks tab, you can actually see that and get the same information as if it was just like VS code.

So, you can see that this was the issue.  It is a help URL that you can click.  And you can see that there are one file with an error and in that file there is a single lint error there.  And it also adds a note here that there is an accessibility issue in the files itself.

So that was everything for my demo.  And I'm passing it back onto Wilco.

 

 

>> Fantastic.  All right.  Let me take the screen share.   And as I promised to keep time for questions I'm going to skip over a few slides, I think.  Um, so as Michaelling mentioned, Axe-linter really fills some gaps and let's you code all of the things.  So not only do you write, do tests whether you're editing.  You test with the axe extension in the browser with axe-- or puppeteer or playwright you can automatically test your unit tests.  And in your Axe-linter brings it up again, really gives you full coverage of your development process to test all the things.

I'm going to skip over this part but I'll just briefly mention that Axe-linter has a configuration file which you can change things like rules and what files are being  linted, for example, if you want to exclude testing files.   You may want to configure Axe-linter for those.  Axe core has lots of failing testing files, for example.

I'm going to skip over this question but it is an interesting one.  How much does it test?  The brief answer is we don't know yet.  The way I like to think about Axe-linter is a quality gate.  It prevented various types of accessibility problems from making it into your code base.   If you're using Axe-linter properly, you have it in your editor, sometimes certain issues are not going to make it  in.  It really stops problems from getting to, ever making it to your development.  I think that's the greatest strength of Axe-linter.

As for when we're going live, we are hoping to have, the GitHub app and the VS codex tension available before the end of the month.  We were encountering issue I was hoping we wouldn't have before today.  I think the end of the month is realistic.  So we will try to get this to you as soon as possible.  And Intel J and is web storm we have a go  already, we just need to get to the release process.  I think we can expect that in April.  And there are more iterations coming later.

I'm going to expand on this slide for future possibilities.   Once my slide deck is available, have a look.  I want to emphasize that there's lots of ways and directions we can go with Axe-linter still.  None of this has been decided.  But it's working on more languages, adding more suggestion, features, there's lots of directions to go.  I think this is early days for Axe-linter.  But I'm very excited to see where it's going to go.

 

 

We are looking for customers.  If you happen to work for an organization that has an Axe-linter customer and you're using GitHub in your organization and using react or vue, shall in contact.  We are looking for organizations to do a GitHub trial with.  Those are organizations that we will give access to in March.  Others will come a little later.

And just to summarize, Axe-linter is an entirely new tool that is a source code instead of WebPages.  It runs in your code editors and IDs and runs in CI and integration environments.

Kicking off with VS code with Intel J and GitHub apps support for multi-at this languages and fully consistent with ax axe core.  And with that I'd like to open for questions.

 

 

>> All right.  Thank you Wilco and Michael.  I'm going to pull these up and thank you everybody for all of your questions.  I believe we have about nine minutes.  And if you haven't already, please upload the questions that you think still need to be answered.  Wilco did a great job answering a lot of the questions but go ahead and keep those questions coming.  We may need to have follow-up webinars to get to all of these.

>> I doubt this is the last time we're doing this.

>> We'll see you all again soon, I think.  Okay, let me get started.  This one has 40 uploads.

What is the difference between Axe-linter and a tool like ES lint plug in JSX Ally.  Will they work will parallel?  How are they different?  I know you had slides on this.  A little bit more of a high level.

>> In short, Axe-linter does multiple languages.  So it's not just limited to react.  It's will test HTML-- the and other benefit is that Axe-linter is consistent with axe  core.  If you're using axe core, if you like axe core, Axe-linter is definitely a good thing to look at.  By all means use them in parallel.  JSX is a fantastic tool.  I think Axe-linter can add to that in a meaningful way.

>> Got it.  Next question from jewel, does Axe-linter integrate with ES lint?  I'd love using the Vue Ally linter but it's limited.

>> It does not, no.  Axe-linter is not an open source project.  It will be available for free in various IDs.  We are till still looking at what the pressing model will be for the requirements.  That information should come fairly soon.

>> Awesome.  Thank you.

>> No, it does not integrate with ES link.

>> And Teresa asks for clarification on the difference between Axe-linter and axe core.

>> The most important one is that Axe-linter tests your source code.  And axe corporate tests WebPages.  So Axe-linter can run on your entire code base * all in one go.   And you just have to kick it off to get started.  Whereas if you're using axe core you have to open every single possible page in a browser either automatically or with the browser extension and click the analyze tool over and over again.   So the biggest benefit is the broad spectrum impact that you get from Axe-linter.

>> Okay.  All right.  Next question here, will Axe-linter be available to organizations repos?

>> Um, Axe-linter is going to be available for a GitHub app which you can install on GitHub to run on your request.  We are looking at other testing environments, code resources, Git lab's been mentioned.  We might do Azure as well.  There are so many possibilities.  The options are enormous, and can we are, yeah-- it's still early days.  We will have to pick and choose, I'm hoping we will at some point be able to cover all of those.  Definitely there's a need there.

>> Thank you so much.  Next question, is there some plug in for angular apps?  On the slide, I saw only react JS and  vue.

>> Correct.  Angular is not yet supported.  But we are

 

 interested to support angular as well.  That is up there in my list of languages to add.

>> And then there's a clarification here on the organization repos.  This person says, to clarify the question about organization repos was about GitHub organizations versus, I think, maybe personal.

>> Um, so the benefit of using a GitHub app over something like GitHub actions is you can install it on an entire organization at once.  So you install it once andling it be available throughout the entire organization.  You can even enforce it so that, once you have the app installed it will no longer be possible to merge poor requests that don't pass Axe-linter.  Regardless of what repository it's in.

>> Great.  Thank you, Wilco.  How do you suggest integrating Axe-linter with precommit hook?

  

  

>> At the moment, you do not.  Again Axe-linter is not an open source project.  So you would use it in your editor, and you would use it in on your-- or CI environments.  You could not, I don't think you can get it to run with  Git being hoos.  I am look at that and think of it some more.    *

 

>> Can Axe-linter filter levels of errors from crucial to low?

>> Not at the moment.  What you can do is enable specific rules or disable rules you don't want to run.  So that -- sort and filter in your own.  We are also thinking about adding capabilities to provide warnings instead of errors.   There might be ways to do that.  We are looking at various solutions to that.  So by impact not securely on the list.   I'll add it-- it's a good idea.

>> Awesome.  Thank you, Wilco.  Looks like we've got a couple more Americans here.  So I'll squeeze in as many as I can.

>> Michael, you want to take any?

>> I'm good.

>> Is Axe-linter available to nonprofit organizations?  Is

>> Axe-linter and the editors will be available for free.   It is available to anybody-- um, for GitHub, I don't know yet.  That is yet to be decided how we are going to make that available.  The GitHub app runs a server that does not run for free.  Servers don't run for free.  So we will have to figure out how to pay for that and the development of Axe-linter.

>> Okay.  Question here from Jim.  Will Axe-linter be able to detect keyboard functionality like if the element in question is can be triggered by enter, space keys anything like that in the future?

>> Yes.  This is currently available for JSX and Vue.  And it is functionality I'm hoping to expand on.

>> Okay.  We have time for one more question here.  We'll go with will there be support for Twig blade templates PHP?

>> Um, it's not as high on my list but we definitely consider PHP as well.  I'm hoping to expand support for lots of different languages.

>> Okay.  And maybe just one more here.  This one just came in.  How can we be a part of the alpha or beta releases for Axe-linter?

>> Um, if you are an axe customer get in touch with your Deque representative.

>> Okay.  Awesome.  I think we are about at time.  I apologize if we weren't able to get to your questions.  Thank you, guys.  Thank you, Michael and Wilco for a great session.  Thank you, everybody, for attending and all the engagement in CHAT and wonderful questions that are still coming in.  But we are at time.

>> I am on select-- if you have any questions.  Feel free to reach out to me.

>> Absolutely.  Thank you all.  Enjoy the rest of AxeCon, everyone.  

Type: Breakout

Track: Development

This joint talk from USAA and Workday will discuss how each organization built accessibility automation into their existing testing processes. In this talk, the presenters will discuss:

 

The drivers behind building accessibility automation into a testing pipeline

How to receive executive buy-in for this process change

How implementation went and the current status of the effort

 

 

I'm Ryan bait man from Deque, I'll be moderating this session titled accessibility at scale. I'm joined by Bryan overtime camp, our principal technical architect at USAA and Tom si Cora, director of accessibility at workday. Before I turn it over, let me address a few housekeeping items. First today's session is being recorded and will be hosted on  demand. If you require live captions, you can access those on the session page just below this video  stream. Lastly, we will save the last 10 minutes of today's session for Q&A but you can post your questions at any time during the session in the Q&A widget.

You can find that Q&A widget alongside chat next to this video stream.

With that said, Bryan and Tom, please take us away.

>> Good morning, everybody. Good morning Tom, how you doing?

>> Hey, Bryan, good morning how you doing.

>> I'm doing well. Thanks, Ryan. So today we are going to talk to you about accessibility at scale as Ryan mentioned and I'm excited to have Tom here from workday. As was mentioned, I'm Bryan oster camp from  USAA. Before we get started, I wanted to give you an example. I'm so thankful that we have got folks from really all around the world here. I'm going to give you an example of something that happened recently. For those of you in Texas you may be more familiar than others. We have that thing called snow down in South Texas which we are not used to. So what happened was basically after we had the snow storm, we had to make some changes where our water filters needed to be changed and worked out. So what I did was I have got this reverse osmosis filter. And if you're not familiar with that, basically the water that comes into our house will have several additional filters to make sure that water is nice and clean and not too hard like it is in the hill country. I'm not a real hands on type person but I decided I can go ahead and fix this. So I did watch a few videos on how to change it. I have got these simple filter things that I just pop them out and put them back in.Esey piecey, no  deal. I said I can do this. I watched some videos. The video said make sure you turn off your water before you do this so that way you don't have issues. I'm like this is easy, you just pull it in, pull it out, no problem. What I did was skipped that step, I wanted to take a shortcut and I decided I'm going to pull out the filter. I pulled it out, not a problem. I was having issues trying to get it pulled back in, it wasn't quite working. And I was like let me just force it, because that's always good, let's take that shortcut. When I pushed it in, apparently it didn't quite seat properly. So instead of it working and me being done, what happened was I had this large stream of water just flowing out to the bottom of my cabinet and I did thankfully have a towel, but that towel got saturated in about three seconds, which was the time it took for me to look at it and realize what's going on. The lesson I learned from that was be very careful when you try to take shortcuts and try to do something against what was advised. And as we start this  session, what I wanted to start with, when we look at scaling and scaling accessibility, Tom and I are going to talk about a few different things and ideas, but one of the things I learned was you certainly don't want to take a shortcut with scaling accessibility either. Hopefully that will be a good way to think about as we're going through this session some of the items and ideas that we might have for that and some of the things may make sense, some may not make sense in your organization, but those are things to consider as well. Again, thank you so much. good morning to those of you it that it's morning. Good evening. A couple are really early morning birds and hopefully you have your coffee and are ready to dive in. I'm Bryan oster camp, I'm a principal technical architect.

 

I have oversight over the accessibility testing space within USAA. I own all testing in USA,a. I also own the assistive technology -- we have a focus space I'm working with several other architects on trying to improve our employee assistive technology and really moving that forward in that space. Those are the two areas that I am a part of at USAA for accessibility. I have been at USAA for 18 years, nine of those years was being an architect and I have been in the application space where utilizing testing technology and assistive testing technology as well as now owning those tools and being in that space and being the provider of that technology. So I have been able to see the challenges and advantages on the application side as well as the infrastructure side. I'm going to hand it over to Tom to introduce himself.

 

 

>> Great. Thanks, Bryan. Good morning, good afternoon, good evening and good crazy morning because I think I heard someone from Sydney, Australia joining the call today. My name is Tom si Cora, director of accessibility at workday. And I have been at workday for the last two and a half years and in the space of accessibility. In my prior role I was working on accessibility for the last three and a half years. We're excited to be here to talk to all of you today. I want to start -- Bryan, I didn't know he was going to share the story. I have been in Texas when it snowed and been in London when it snowed. I can testify [Away from mic] I don't know how I made it. I have got to ask Bryan, in the COVID era, Zoom backgrounds are like coffee table books. Bryan, what's up with the medals?

>> Before all the COVID stuff hit, I ran Spartan races. For those of you not familiar with Spartan races, essentially those are races where we run, it could be five, 13, 26, 9 miles where we run and we climb holes and go underneath barbed wire and throw spears and have a fun time getting bloody and sweaty. That's what that is. For those of you that are Spartans, ba review, you will know what that means. Every race we run, we get the finisher medals. I think I've run about 15 or so of those. It's a good fun time for those of you who haven't done it before.

>> I knew that about you. It was interesting though because in between earlier this morning and now I actually ran to my mailbox. I'm a return and also a triath lete. Bryan's got me thinking about challenging myself. I dug out this one medal. This is Ohio  stadium's this is a finish on the 50 run where you get to run and finish inside the horseshoe. Ohio native here who knows how to drive in the snow. By the way, there's no adventure racer future because upon I'm not a very good trail runner. Anyway, on to our conversation. Bryan, we are going to go over our agenda to get it started?

>> Absolutely. Today, like we mentioned, I'm from USAA, Tom is from workday and really what we are going to talk about is some high-level themes that we've noticed both in scaling our DevOps accessibility journey. What we are going to do is go over the individual themes and then how our organization handles it. What I'm excited about, because both USAA and workday are sharing their perspectives, they are not necessarily the same. Some things we did that were similar but there's also some things that were different. I'm excited to kind of share those differences and I want you to understand as you're watching this that there's really no one size that fits all. We know each organization is different. What you tried to accomplish and what you see that we might have done, hopefully you'll take some of the tidbits from each one of the learning we've had and maybe share back with the community what you've learned as well. Three of the themes we are going to talk about today is how do we empower our community to be able to help us build that accessibility to scale as well as secondly will be how do you show that view at an enterprise scale and Tom will share his perspective and I'll be sharing mine. Last Tom's going to talk about how do we catch regressions or what are the benefits of catching those regressions.

>> So it's interesting and I look forward to the Q&A period of today's conversation to see what kind of questions we get on this topic. This is more of a prompt to think about where you and your organization might be in the journey for accessibility. Are you starting with one or two people in the corner of your office that have low or no air cover from your organization?

Or have you just gotten back end for this to be a priority in the organization and trying to figure out what to do and how to level up on this?

And when you really think about, depending on the size of your organization, what are models that actually can work at scale. I think a lot of people when they get into this space look at this as a problem to solve as opposed to some cultural changes as to integrate the thinking of accessibility throughout your organization.

So as you kind of think about where you are in the journey, also look at your organization and think about how you want to approach this from the organizational mindset side of things. It's not just about accessibility and design, coding and keying, there's a lot more to do organizational-wise to get your company to a place where this is just something that is done because it's how we get work done.

Next slide. All right. So you know, many of you probably are also in that situation where some people in the development community look at accessibility as something they will fix later or as I call it "fix in the mix." And many of us know it's not like a record producer where you call and they fix the sound of your band before the album goes out. Here's a smattering of different roles that I think are fairly straightforward when most people think about accessibility where you need to teach people to fish in your organization. I want to talk a little bit about my experience of two different operating models that I've worked in because how we've approached accessibility and how we've tried to solve it at scale has been different, more because of how the organization is structured and the size of the organization. So I'll give you a tale of two organizational models. The first one is what I call a federated or decentralized model of an IT  organization. In my background, I work for a large bank here in the United States and just the largest of the technology population was greater than 25,000 people globally working on technology for the bank.

And the landscape was well over 600 applications that presented itself as a dot com and behind dot com was about 600 applications, many of them back end, transported to the would I be. We had obviously a bank and lots of documents and documentation and PDFs pulled from all over the place, various data sources and other inputs outside of the company. Also, third-party apps and third-party apps that are integrated into dot com experience but you're actually porting out to a third-party vendor who is not necessarily the same accessibility experience as when you're inside the firewall or inside the experience of your company's app. So you're kind of looking at that and thinking how do you approach accessibility and drive that into your organization is obviously very complex. If you're looking at centralized models for accessibility, how do you get into those organizations and drive accessibility across such a large space?

 

 

Then there's another model. Think about another side of the house where you have a more centralized approach. I'll give you an example of where I work today at workday is we call it UI metadata platform approach, I call it a super platform. Most of our development is in a centralized environment. We also work in a foundation of reusable objects as well as reusable layouts. So mostly in the foundation of a product is developed with tons of reusable components. So it's a little bit easier to approach, fix it once, fix it everywhere for a lot of things that that are components in our product. In my experience, how we've approached accessibility and driven it across the organizations has been very different because of the way the organizations are structured. If you follow on to that, this story that Bryan and I are going to talk about for the rest of the time this morning is some of the unique things we've done that actually go beyond what I just described as some of the traditional sides of accessibility. I'll start with the workday story on this is where we're looking into some tooling options to help our community and teach them to fish and get them the right tools for the job, we were looking at some automation tools. I had the benefit as we were evaluating the various vendors, we brought in our director of DevOps into the conversation. I don't have a background in DevOps. We brought him in because he runs a lot of our automation. It was interesting, he asked the basic question:  Can we actually put these tools into our continuous integration build pipeline?

And I never considered that as an option.

So as we looked at tools, that was one of the options that we chose as workday to provide people with the right tooling for the right jobs and kind of introduced this into the space so we can actually have an enterprise view and look at accessibility at scale throughout many parts of our development organization.

That's just kind of to tease you a little bit for the conversation about looking at how we've applied some of the DevTools into more integration at scale. I'll turn it back to Bryan.

>> So the next piece we are going to talk about, the first thing is empowered community. So Tom mentioned about several different aspects of a community and not just having one central area or one central theme of knowledge but really how can we empower that. Tom talks first about his perspective and I'll dive into the USAA perspective as well.

>> So kind of spring boarding off of that, the right tool for the right job, there are lots of things that we can do to actually help the various roles in the organization to improve. And we work off the  mantra that the [Away from mic] expectation through our organization that accessibility is everybody's  job. And going back to that, you can't fix it in the mix when you think of everybody on the left-hand side of the equation trying to fix it in either dev or QA. Really you are reinforcing the point that everybody has something to do and there's nothing necessarily special about accessibility. It's just a new skill set to learn for your role. We have redone some of these things and we use the expression carrot first, stick later. No surprise, obviously we have a very robust training curriculum at workday. We've developed it to the point where we do it like a college curriculum where we're now up to 300 level classes with very different roles and it's not just development QA and design. We actually have training for content management for marketing website participants as well. We are going to talk a little bit about tooling, but one of the ways we also provide assistance to our organization is through the use of office hours with our design and development communities, again, to not create the situation where we create a co-dependency in the organization but we're here to help rather than solve the problems for them. One of the things using the DevTools in our automation has helped us immensely and one of the reasons I say that is because one of the challenges we still have at workday is we are still helping our development community where we collaborate with them as they're working on new features and shipping products to telemebed the success criteria from the development and testing into their geostories, for example. We are not to the point where we have taught everybody to fish and they are fully independent and sustainable but obviously have a roadmap to get there. I want to talk about one story aside from the traditional development model side of things and this really goes down to creating and setting an expectation and how that can drive organizational change. So it was 2019, I had just joined workday shortly before that, we were very fortunate to have one of our executives champion accessibility and we made it one of our top level goals for 2019 to improve the accessibility of our product. Who doesn't want that?

You get some amazing air cover and support to really drive change in the organization. And looking at 2019 we had a lot of work to do on the product side of things. We had the heat map and roadmap of where we needed to make our initial investments in accessibility. One thing that actually happened in this that wasn't on our plan or roadmap or heat map, but our marketing team approached us because they knew it was one of our top level goals for the company and asked us what do they need to do. And even though it wasn't on our roadmap, we certainly looked at it as an opportunity to partner with them. Our initial conversations were about what we need to do to fix it. And we continued to really challenge that line of thinking to say let me teach you how to do this because marketing content and making it accessible isn't a special skill; you just need to learn how to do that. So somewhat of a protracted conversation to make sure we were getting to the right operating model with the marketing team. And in the end, we ended up launching a new marketing website late last year and it's fully accessible. I think the important part though out of this is that after we finished all the work, our marketing team is self-sufficient and working on all new content with -- they work with some third-party agencies in support of that and making sure that everything we put out is accessible and they're self-sufficient at doing that. I think when you really look at accessibility at scale and looking at various roles in the organization, you set an expectation that it's your job, if you learn to level up their skills, by then the tools and resources, that's when you form not just the scalable side of things but also sustainable, things that people can repeat time over time. That's a little bit of a workday story. I know Bryan's got a different look on things.

>> Thanks, Tom. Yeah, so the title of this slide is don't succumb to learned helplessness. It's something we started in the last few years using on our side, which learned helplessness essentially the definition is when an individual continually faces a negative uncontrollable situation and then stops trying to change their circumstances even when they have the ability to do so. So in other words, it's something I know how to do and it's been a while since I don't have to do it anymore, I have learned this  is -- I basically choose to not have the ability to do this. The reason that's important in the story at USAA was several years ago we had a whole separate testing organization. All of our testing, not just accessibility, but all of our testing was done by a whole separate organization. So what we had was, unless you were QA or tester, you didn't do much testing, right?

I know a lot of you are like that's scandalous. I agree. That was where we were. We were like the team can be responsible for quality so let's start shift testing to the left, et cetera. Over the years we have been on the journey to move that testing really to within the Scrum teams, for instance, but then we also had specialized testing. So in our space that's accessibility, security, performance, et cetera, that was still done within the center of excellence area. So what happened was the teams were still learning how to be able to be responsible and automated testing, et cetera, within the organization, but now we have this specialized testing organization that also needs to be moved out to the teams. What we have now is we have really all of our teams are responsible for testing and then we're starting to role the accessibility testing over to the team as well.

So what we started seeing from this perspective was the same thing where we need to roll this out to the organization. Tom mentioned a great example. We need to make sure we provide the right tools, right?

  

  

So one of the things we saw was we had some of our leaders in the infrastructure space say hey, let's start transitioning the accessibility testing over to the teams. So as the architect, one of the cautions that I had in the conversation we had was it's really important before we transition the process and the abilities to the teams, we need to make sure we provide the right tools. So it's really important, for instance, to have a DevTools, pipeline tools, DevOps tools that allow teams to be able to check their coding and run accessibility right away or, again, security performance, whatever it might be. You want to empower the teams. So when you start looking at scaling your accessibility across your organization, make sure you provide the right tools. And also make it easy to transition. So a concept that we have at USAA is we want to make sure, we call it the testing freeway. But basically we want to be able to provide you the ability to have support and training for the tools if you have issues as well as a quick start way to where you can very quickly run something within the pine line. So an important thing that we learned and I think that saved us some challenges was let's make sure we empower the teams, train them, help them understand how to utilize it. And by the way, when you're moving from a centralized model to a decentralized model, whenever those tools provide you insights or have findings, it's really important to have a tool that says not only here's the issue, but here's how you fix the issue and this is why this is an issue. In the assistive technology space, this is what challenges someone would have trying to utilize this tool. So it's really important to understand  that. I think the other thing that's important to remember as well, there's going to be some teams that are going to embrace it, they are going to love it, move very quickly and say we are going to do this. But you're going to have some teams that will never be ready. There's always something, some challenges that they want to keep working through before it gets transitioned. Those are the folks where you have to say hey, let's jump in with both feet and do this. Some teams will be ready, some won't be, but eventually you have to step up and make that transition. When you look at scaling, find the teams that are passionate and excited and want to start using the new tools, but you're going to have lagging indicators as well on teams that aren't quite ready and at some point you have got to have them jump in. That's important. And then lastly, really quality is the responsibility of the application team so you don't need a separate organization, you don't need a separate individual, and there's all sorts of different examples of teams that do have a separate QA and there's examples of teams that have them combined. Really any one of those solutions can work, but something to consider is when you're scaling it out, like Tom mentioned, you really want to help everyone understand the value and the importance of it and not just relegate that to a few individuals.

So next we are going to talk about viewing at enterprise scale.

>> All right. So it's interesting we have been talking about looking at scale and just in general how do you have the model that you can actually ramp-up and still have control of what's going on. When we start thinking about this at workday from a tooling sense, kind of reiterate that my background prior to joining workday was in banking. And I think when I was looking at the tools, there was more of a compliance side of things to really have [Away from mic] and controls, if you will, or a back stop, the last possible point in your construction of your product, how do you just have that last quality control?

But it was really interesting when our DevOps person started asking as we were evaluating tools:  Can we actually put this into our CI pipeline?

It was a question we hadn't really considered until he posed the question and in my mind I thought wow, let's really think big about this. Why do I say this?

  

  

Let's look at some of the other ways that you can test for accessibility and talk about the Axe browser plug in. It's obviously a fantastic tool. It's one of the de facto standards in the industry out there. But when we were talking to Deque about this early in the cycle, it was snapshot and you play your chat and it disappears like a puff of smoke, kind of like Mission:  Impossible. And a lot of times results from those end up being screenshots that get put into other project documentation whether it's Jira or other tools. Coming from my background, always wanted to get to having line of sight into what's going on in the testing activity for accessibility and really what are the capabilities available to us today to get that. So as part of that, we decided to go on that bold step to introduce this into and use the enterprise version of Axe DevTools into the workday pipeline. I'll tell you a little bit about the story of that. I'll say I was very cautious and concerned that if you put something in the build pipeline that you could potentially fail your developers build for, if you don't do it right, you will have the barbarians at your gate. I need to merge my code because I have to ship my product. That really goes back to the carrot first, stick later. So we spent the better part of the year and a half in our organization working on carrot side of the training, the tooling, the right tools for the right job, setting the expectation within our community that this is expected of them so that by the time we went to turn this on, we were hopeful it wasn't going to be this controversial, if we were going to do this thing and turn it on and [Away from mic] figure it out. A little bit more of a process of how we got there as well. Just for transparency, most of our automation in our CI pipeline is through web driver IO and cypress. We did spend a little bit of investment at workday to put some wrappers around them so we could drop [Away from mic] workday. We started with very small pilots. One of our development teams locally here in northern California, and it was really interesting and I'll qualify this by saying I did not do the work to put the wrappers around the Axe DevTools, but I'm told it was fairly easy. It actually was a fairly simple for us to do that and the results were pretty amazing. Share with you that after that, we're like okay, we'll take it to some of the development organizations here in northern California. And my Vice President challenged me right on the spot and said take it everywhere, if it's that straightforward, implement it everywhere. We of course heeded that call and decided that we were going to implement this throughout our entire development organization. So it's been a pretty good story from there. Next slide. So what's really great about the fact that we have this installed in our CI pipeline, this is just a mock-up of [Away from mic] visualization tool on this slide is a couple things. One, we get line of sight into the actual activities of where we see failures across our development community. Probably the best benefit we get from that, I always look at what's my top five WCAG failures today, my top five WCAG failures of my products at workday would be different of somebody else's based on the unique attributes of your product. If I use that information to inform us, we can then recalibrate our training and have subsequent waves of training or improve our training over time to really improve those top five defects and see fewer and fewer of those. If I remeasure the top five defects a year later, hopefully I'll see a different top five. So the real big benefit that we see from having this is to be able to calibrate and really level up our development. The other cool thing that we've done is out of that trepidation of [Away from mic] barbarians at the gate is you can customize which WCAG failures will actually fail your build as you're trying to level up your organizations so you don't have to turn it on and everything fails, you can tune it based on where your organization is on your accessibility journey. And the last thing I'll share too and Bryan will take us through some more of this is the nice part about when you're using the DevTools enterprise version is all of this is exportable, comes out in JSON, this is our data visualization tool of choice but you can pull this into any data visualization tool you want and then drive that into the rest of your CI dashboards, if you will. I think Bryan is going to share with us the USAA perspective on this next.

>> Thanks Tom.

So when we looked at how do we scale at the enterprise from a USAA perspective, what we saw a few different things. First was, and Tom mentioned this, this is not specific to accessibility but this is in general the approach that I take. At USAA we have pretty much every programming language you can think of and I'm sure we have a few we've made up ourselves. Whenever I'm reporting my results to my test case management solution, we wanted to make sure we provide one API that reports all the test results regardless of what tool it is, et cetera. We mentioned we have the tools that Tom mentioned as well as many other ones. So we didn't want to tie it to an individual framework or individual test tool. Really as long as I report the results to our centralized API, then we can give the results and because we are a heavily regulated industry and organization, for us that's especially important because all these different tiers doesn't matter, it's important to show we're compliant and doing our testing properly and we have quality. That's the first thing. The next thing, what we wanted to see, and this is actually a learning I had myself, when I first came into the testing space and was trying to -- there's all these different various tools you can use for testing, what I said was hey, let's have people go to the dashboards that the tools provide. So tool A has a dashboard, tool B has a dashboard, you can build the awesome visualizations and let's just use those. What happened is I started discussing these conversations with some of our leaders and one of our top level executives basically said, Bryan, I'm going to look at one dashboard and that's it. So if the data is not on that dashboard, I'm not going to see it, I'm not going to look at it, eaten going to know about it. That was a very quick way for me to go great plan but that doesn't matter because they are not going to look at it. What we started to look at is how do we provide all the data on one pane of glass to make sure the information is there. When we look at the overall perspective of what that is, I'll give an example. At the top right what you will see is I have got something called number of test cases run. So you have manual and automated test cases. That's something standard you might see. Next one you might see is number of test cases run, I have got 12 failed, 8 incomplete, 160 passed, which provides you some amount of information. But what we want to start driving towards is on the bottom right which is here's the number of test cases I've run, but let me break it down into security, accessibility and performance so you can start understanding from that perspective, you have a high-level dashboard and you can dive into individual areas and say here's the number that passed and here's the number that's  failed. That's what we're trying to drive. You have to dive down deep into the information. Tom showed the example he gave. Maybe you dive down from this level and it will show the type dashboard he has. That's something to consider. Real quick, in the reference of time, when you think about accessibility testing, you have got automated and manual. Make sure you're pulling it into one test case management solution. And like I mentioned, regardless of what the testing tool is we might have essentially what we have on this is on this diagram we have accessibility test, performance test, functional test, security test, static code analysis, all of those flow into the test results like I mentioned before and go into Data Warehouse. Regardless of what tool it might be, let's make sure that we provide the API for that example. I'm going to have Tom talk next about catching regressions.

>> And maybe just a last story, promise. So after all of this it was really interesting, I was talking to one of our dev managers about why are we seeing numbers that are so low what we're seeing in the build pipeline?

He peeled that back and the real short version of the story is that most of our developers know they will fail or build so we're beating it in the [Away from mic] test so we're driving the right behaviors into our development community. We had one build fail a little while ago and the developer came to us and it wasn't like what do I do. It was like here's the error I got, here's the tool tip I got, I just wanted to run this by you, am I doing the right thing. I was like congratulations, you broke the app widget. And he was like what?

It's that space where you want to be, where they knew what's to be expected, they got the error and they just looked to us for advice and consult. That was to me a really great capstone of from the pilot to a couple months later applying to the entire development community in a sustainable and scalable way. So I think that wraps it up for what we wanted to present to everyone here today. I think that opens us up for Q&A, Ryan?

 

 

>> Yeah, Tom, Bryan, thanks so much. Fantastic. We have got a lot of chat. A lot of great questions. Let me start with the most popular question, which I think maybe both of you could weigh in on. It is:  Are there any accessibility training tools you recommend?

>> Training tools?

I think I'll answer this a little bit differently than what might be expected for the answer. I think many companies do this. We have what's called an accessibility research and training lab. It's a physical space in our office here in California but have since transitioned in the COVID era. There's lots of tools available to you actually at the Axe products available to you, lots of guides and how to's to help you understand the error and coding [Away from mic] those are good tools. I think we have taken the approach where training by role type in the development life cycle has been very helpful to us. It helps set the expectation of what's expected for the role and making it everybody's responsibility.

>> Yeah, I think I would say the same thing. I'm of the internet generation so I usually go to YouTube and try to find examples. That's usually a good way to do that. I've also done several different things within our organization we've got some great accessibility leaders. So we have even a lab where people can come in and learn about the tools and it may not scale as much, but it's a way to really help some of the leaders understand the value of, okay, how does trying to use this application work if I'm using a screen reader, for instance?

Those are good examples. Quite frankly, one thing I think is great about a lot of these tools is, again, a great way to start learning a tool is start using that tool. As it shows findings and shows issues, like I mentioned, a lot of these tools will say this is how this might be impactful. So if you start thinking about how if I used a screen reader, how I wouldn't be able to utilize this or if there's not captioning, et cetera, and it helps you understand the impacts of that, that can be a really good way to help it hit home for someone.

 

 

>> Thanks, Bryan. Yeah, a lot of good tools out there that will enable you to learn while doing,  right?

You touched on this a little bit. Maybe it's worth reiterating since it has a lot of up votes. This question is what tools are you -- I'm sorry. What tools are you making use of in your CICD pipeline and how?

Maybe we start with Bryan this time?

>> Sure. I can't go into like specific tools but I can tell you the capabilities that we have within our pipeline. So within our pipeline, obviously we have got unit testing, integration, we have got functional. We actually do security tests in the pipeline, performance testing and accessibility testing. So really what we've embraced with this and this is something I learned a long time when I was a developer, if you don't automate it or it's not within the main pipeline of work, it's probably not going to get done. So the most critical thing for us is make sure you're running those tools every time you do a check in from a CICD perspective or if you're not quite there yet, making sure you run those tools daily and teams are looking at it. Certainly we use all the tools within the pipeline.

>> That's a good point. One thing I forget to mention is let the machines do what they do best and let your experts find the things that are hard to find. Run half hour the host of tools there are, but run the automations first. Then once we get to the stuff you can't automate, that's when you have the experts and you still want to train, help them understand that, but utilize those tools as much as you can so you don't have to spend your time and money doing something that a machine can do.
>> Yeah. Thanks for that. There were quite a few questions in here asking about what y'all do with the manual testing component. Okay. Another popular question. How can someone start to advocate to include more people in accessibility training, not just more devs but product managers, designers, marketing, et cetera?
>> I'll tell you that I do a lot of road trips inside of my company and get in front of various parts of the organization. If I have an opportunity, I'm there to present, again with that mantra that it's everybody's responsibility. So one of the ways that we've done this at workday and many companies have, they may call them different things, we call them OKR, objectives and key results. We do these every 90 days, our goals against our high-level objectives. One of my pitches that I make and usually come out with a full class after telling people they should make this an OKR for the organization and they do. The OKR is to have everybody trained up on this. Just on the Axe DevTools I want to make sure every developer has been trained up on this. And we got 100% participation. I was shocked that we actually got that. It was because we made an OKR and people know they want to meet their goals and objectives so that's how workday pitched it that way.
>> I would add a couple different thoughts to that. One is be aware that so like I talked about quality that is everyone's responsibility. I have heard quality is everyone's responsibility, security is everyone's responsibility, all these things are everyone's responsibility. So be aware of it's my responsibility fatigue. So help people understand also, again, what's the personal impact, what's the personal value thaw see this, what happens -- so if you have an individual that utilizes those tools, have them explain potentially how it impacts them and their situation and their utilization of those tools. I know for me, that's how our leaders caught me, right, was hey, let's go talk about this, let's fully understand what this might be. For me, that was really helpful was actually understanding the personal side of things of how this impacts someone's daily life utilizing these tools. So I think that's important when you start understanding the implications of those tools and when something's not accessible, how really it can impede someone's ability to utilize your website. There's certain different ways. There's also the financial aspects that have as well. The community that utilizes those tools, but I think for me it was making it personal and understanding how important this is is really important.
>> Fantastic. Tom, Bryan, I think you have gifted us with a lot of great knowledge. I really appreciate both of your times. I want to thank everyone who took the time to view this and take away some notes and maybe start to put these things into action. Thank you for attending and Tom and Bryan, thank you so much.
 

Type: Breakout

Track: Design

As a creative director, I’ve consistently been presented with designs and experiences that target a specific, typically abled audience. This talk will educate designers and the accessibility community on typical ways accessibility is forgotten in the design process and tactical, design-focused solutions.

 

>> Hi everyone and welcome to the session. We are going to get started in just a few minutes to allow some other folks to join. Please hang tight in the meantime.

 

 

 

>> Hi folks if you're just joining and you're looking for how designers forget to consider accessibility, you're in the right place. We are going to kick things off with a few housekeeping items in a few minutes here and then we'll get into Brandy's presentation so please hang tight.

All right. Well, it is 7:30 Eastern Time so I think we'll go ahead and get started. Hi everyone. Thanks for coming to the session. My name is Grace Kirkly, I'm with Deque and I'll be moderating how designers forget to consider accessibility with our guest Brandy Bora, design director with Verizon. I have a couple quick notes for our attendees. I'm sure those of you who have attended multiple sessions earlier today have these memorized but I'm going to go through them real quick. First off, the session is being recorded and the recording will be available to watch on demand on the presentation page that you're currently on after the presentation has concluded. Live captions are available below the video screen and the slides for today's session are accessible and also available on the presentation page where at the bottom it says to documentation, there should be a button there. If you don't see it, you might have to refresh your page. Finally, we'll save about 10 minutes or so of today's session and dedicate those to Q&A. Please post your questions as they come up in the SLIDO Q&A section that's right next to the chat module, also located next to the video screen. And I recommend sorting the chat by recent so any new comments scroll dynamically up to the top. With that, I'm going to hand things over to Brandy to present.

>> Thanks!

Well, let me tap into my little presentation there. Okay. Awesome. There's some little notification waiting for me. Great. So thank you for joining my talk today, how designers forget to consider accessibility. To go through the outline of our discussion today. First we are going to talk about who I am and talk about what my point is. Then we'll go through the design process. The design process for this presentation will consist of the engage phase, discovery phase, design phase, delivery phase, implementation phase. And we'll talk about some opportunities to improve accessibility and inclusion in the design process and then we'll summarize some of the points that we've made in the conversation.

Then hopefully we'll have a lot of time for question-and-answer.

So hello again, I'm Brandy. I'm a creative director at Verizon. I have a picture of me here with a wiggly gif of a mask. I have about 20 years design experience. I've designed a lot of different kinds of things. Signage, different applications, desktop, mobile embedded, physical objects, websites, games, immersive experiences and processes. The company I work for, Verizon, is a U.S.-based telecommunications company with 30 plus million users. We also have hundreds of designers and thousands of developers and dozens of partners and vendors that work on our digital platforms. I'd also like to shout out to our awesome accessibility teams. Some examples of things I've worked on. This is a page with a lot of different pictures on it. I have a picture of a series of remotes I designed along with a lot of other people at Comcast for the Xfinity remote experience. I've designed a bunch of applications. I have an image of the current Verizon app that I work on. I've designed party games. I have a picture of a party game I designed by Southwest a long time ago. Also used to work on the American Express Serve card payment platform. And then I designed this piece of street furniture that informed the New York City link  service. If any of you live in New York City, there's a public telecommunications instrument for users to interact with that gives you specific information, free WiFi, and allows free calling. Disclaimer before I get into the crux of the conversation. Some of the opinions that I express today are my own opinions and they're based on my own experiences and observations trying to make accessible designs. And a note on how I created this document if it's helpful to anyone. The document was originally created in Google slides. I'm presenting it in Google slides. It's exported into PowerPoint and PDF that's being shared. And then Alt text is prepared for each image and each gif I'll share and I'll describe each one I use today just in case there's any difficulty accessing the  descriptions. What's my point?

My point is that designers forget about accessibility. It's not that they don't care or it's not that they don't try. It's that for a lot of different reasons that I'll get into today, it's a part of the design process that's just forgotten. I'm showing a slowly moving gif of a really common example of a design talking to itself or a design creating things that are inaccessible but for a specific set of reasons. This is a slowly moving gif of a desktop website for the recess beverage company. The recess beverage company is a CBD-based beverage company that when originally launched had a very specific look and feel to target a very specific demographic. With that, the designers they for their desktop website picked up visual cues and trends that spoke to the audience. However, what happens in practice is a design that has some accessibility challenges. If you're able to see the slowly moving gif, you can see a lot of content that doesn't follow a clear hierarchy, it doesn't follow a clear grid, and the grid and hierarchy slowly breaks down more and more the user scrolls. And that free floating disorienting feel is meant to mirror the feeling you might feel while drinking recess, the  CBD-based beverage. And so this kind of conversation of who we want to design this for and the way we want it to feel begins a conversation leading towards an eventuality that design gets carried away with, leaving out how lots of different people might be able to interact or not be able to interact with that experience.

So one thing I've often heard as someone who's been through the design process with a lot of different teams for a lot of different reasons is that accessibility is often an after thought. It's too much work, it's too expensive, or it's not on trend. These are perceptions that different teams I've worked with have had. Here are two very popular examples that I've included here for reference. One is the original version of acorns, acorns is the financial management application. It's a complex piece of data visualization that shows where at any moment in time a user's projected balance might go should they continue to invest or include more money in that investment. There's a lot of tone on tone here. There's a lot of gradients. There's a lot of movement. There's a lot of numbers. There's a lot of content and it can be really difficult to parse. The effect is it looks smart. It looks complicated. It looks like money is growing and things are moving and positive emotions and smart things.

However, it can be really hard for somebody to understand this and use it or interact with it.

And then the dominoes pizza tracker which I'm sure at this point a lot of people are familiar with. I can't tell you, I was a consultant at the time that this launched. I think every client I worked with wanted this. They wanted a version of this for their own application. Not really considering how difficult or limiting it was to use something like this.

So as a designer or as a design consultant particularly, when a client comes to you and says,  hey, I see this in the real world and I see lots of press about this. I want you to do this. Make me a version of this well, that's the brief, they ask me to do that. How can I, the design consultant, unpack that or talk them out of that, especially when they have such an explicit ask?

Another contributing factor here is that project time lines are packed with activities that already over commit individual designers. So in an agency setting, it's not uncommon for designers to work 60, 70, 80 plus hours a week to satisfy demand for deliverables. So a client has hired a design firm or design team to help produce their idea. And now that they've hired that team and spent the money, everyone wants to make sure that the team is being productive and making lots of things. So they quickly cram the day with deliverables. So I have two images here to support that, showing on the left a complicated time line with lots of diamonds representing deliverables and lots of different lines representing work streams. On the right I have a screenshot of my actual calendar that has multiple overlapping commitments in each time slot and lots of overlapping out of offices for all the people on the team.

So then accessibility's often relegated to the implementation part of the process. So let's say we're a design group, we have been hired, the group that hired us feels like they know what they want. They want a pizza tracker for their particular problem. And we have got a design process that we're committed to working through and it's crammed with activities. If at all, accessibility is assumed to be part of the implementation process. So we'll go through our set of activities and then someone at the end will make whatever we do accessible. So in the typical engage part of the process, I'm showing a line here with a bunch of bubbles on it. Those bubbles represent different phases of the design process. The first one being engage, usually the purpose ever engage is to frame the problem and engage designers. This is usually led by the client on an agency client relationship or the business owner or the feature or the product owner or somebody who needs design or needs a thing.

So they will come with their idea of the thing. I think I want design pizza tracker for whatever my problem is. And then you the designer might have some opportunity, might have some opportunity to rework or reframe that with your partner. Some activities, you might start with a request for proposal. You might work through statements of work to engage different people to work on your problem. Then there's the discovery phase. This is where designers learn more about what the problem space is. You might do a lot of activities to gather requirements or understand the problem better. You might stakeholder with all the people that are involved. You might conduct secondary research. You might do some competitive analysis. These are all things you might do to better understand the problem or problem space. Then there's the design phase. This is where the designers will describe the experience and depends upon what you are designing. You might draw things, sculpt things, list things. Some activities are trend mapping, concept design, different fidelities of user testing and ultimately describe the final design in whatever way is meaningful to the problem you're trying to solve. Next is the delivery phase. That's where you document whatever the design is. Again, there's a lot of flexibility here. It really depends upon what you're making but activities are design documentation, user stories, grooming if you're doing software. So that's where you've designed a thing, everyone's agreed on the concept of that. Now you need to basically teach other people how to participate in the creation of that design. So that's specifications, blueprints, a CAD model, whatever it is. This is different artifacts you need to teach people how to make it real. Then the implementation phase. The implementation phase is when we build the thing, when we make the things users are going to interact with. For the rest of the conversation I'm going to talk about software design because that's what I know best and spend my time doing. If you're not interested in software design you can expand what I'm going to say and apply it to whatever kind of product making or thing making is relative to you. Some activities here are development, user assurance testing, visual testing, assurance testing. And then this is where people typically think of in my experience, accessibility testing might go, if it's part of this process at all. At the end it's lumped in with all the other testing activities as some kind of validation.

So to dig a little bit deeper into each one of these phases starting with engage, we are going to talk a little bit about SOWs. I'm not sure if you can see my window in Windows so I'll collapse it. Talking about two specific artifacts, RFP and SOW, requests for proposals and statements of work. Those are designed to get a design partner help a team create things. The language in both of those things is usually very focused on the business needs, the outcome or the KPI that's measurable and important to the business. The time line and the specific artifacts that the designer will make. Sometimes they might specify attributes of the visual design. They usually don't describe in too much detail or have too much flexibility of other considerations. I pulled some language from past SOWs and RFPs I've worked with. The past one are the designers will spend at least 10 weeks creating at least 15 to 20 screens for app and web. Another is they will work with business partners to understand business requirements. They will reflect our brand style guide while staying ahead of trends. They will understand the needs of new market segments, produce 1 to 3 hero flows and 10 innovative concepts that appeal to them. And then words that are often used in SOWs or RFPs are innovative, push trends, contemporary, fresh. That kind of language is used often when part of the purpose of the design is to address some look and feel or user experience softer needs that address some kind of perception that the brand or the brand experience or the UI experience is not aligning to some benchmark, either with a competitor or with an analogous industry or with the expectation of the end user.

In the discovery section, typically in discovery you'll be given a persona or segments or person I or archetypes or some information to describe who you should be designing for. I have two images here. One of a persona named Jim Smith and one of a stakeholder named John Jones and they're images of two men that look very similar to one another. And in my  experience, especially working on a lot of financial applications, this becomes a true experience, at least for me. Personas are often generalized and typically abled. This means I'll be given a piece of  information. I want to design a financial experience for our Jim Smiths and it will give me information and an image like the one here of a Jim Smith, and I'm given some financial information about him and I'm given some general demographics about him. But then it's assumed that he is typically abled. In some cases it's called out specifically additional  considerations, but generally the assumption is typically abled.

And research usually focuses on the experience of those people and competitive analysis doesn't really consider accessibility. So the design team might be given information on the performance of demographics, but the demographics or the performance of a particular product or experience or comparative or competitive analysis doesn't take into account more than gender breakdown or age and it's a good thing if we can even get those pieces of information. And then design. In the design phase, designers often sell stakeholders designs that are inaccessible.

So design activities collage trends to determine what users and stakeholders like. The inspiration that's pulled is often not accessible and stakeholders and users that are responding to those prompts are usually typically abled. On this page I'm showing a lot of images of slowly moving gifs of different inspirational images of fictional applications that come from places like the Hans or dribble. These are all focusing on motion concepts. And as a creative director who runs a product, I see things like this all the time. A team of designers are asked to pull together a trend or asked to look out in the world and see what's happening with a particular interface challenge and what they will bring back is a bunch of things that they found from dribble or enhance that came from different designers, portfolios from design school, and none of these things reflect real usable  UI, especially at scale. They reflect some kind of emotional or highly visual or motion sort of experiment.

And in great cases, we can pull from this things that we can use and make accessible to everyone, but in most cases, someone will fall in love with a very specific visual prompt and then the conversation will turn south into well, why can't we make that, why can't we make it exactly like that, how have we failed to make it as good as that?

These are the kinds of negative framing this this kind of activity often devolves into. Another issue that is common in the design phase is testing. So in the design phase we do lots of different types of testing and lots of different fidelities of testing. But low fidelity and medium fidelity prototyping are really common. And testing platforms have a lot of technical limitations. Beside the technical limitations users selected for early testing usually represent the market segment. If you remember earlier in the conversation, I showed you two images of a persona and a stakeholder that represented or resembled each other?

Often to further that, what happens is the testing includes people in that segment. And that seems to make sense, right?

You want to make sure you're designing the experience for the user who will use the experience. But we often forget to include ableament as part of that. We don't include people who may have challenges using the thing you designed.

So they are not part of the screening process and therefore they are not captured and included  discretely as parts of the test. And then quick prototyping tools and platforms are usually not usable by assistive technologies. So that's very limiting in how you can validate early concepts with users using assistive technologies. Two images that I have included here are from my real life. I work at Verizon using envision as our prototyping platform. The image on the left shows a complex state where we're replicating an OS modal on top of an inscreen modal. Because this is a flat drawing, a user using assistive technologies cannot interact with this screen in any way.

So we have to come up with other ways to make sure that our designs are usable early on. And then the one on the right, we were given a design hypothesis from a partner design team pretty early that leveraged this really heavy use of a very bright red color. And we had early doubts about the use of that color. We know it doesn't pass on most sizes. So we did some design experiments and tested it in envision. So yes, we could do some testing with some users that have color perception challenges and vision challenges, but it still wouldn't work with assistive technologies so we have to come up with other ways to test it to validate early on.

And then the delivery phase. So here I'm showing a gif of Mr. Burns of Homer Simpson, the caption says thanks for your feedback and the gif is of Mr. Burns taking a piece of paper, putting it in the shredder and then throwing it out the window. My point is now we have been through most of the design process. The designers have been given a brief and a specific person to design for. They made sure that they designed something on trend that the stakeholders and users liked and everyone's fallen in love with it. Now we're ready for delivery. Once that concept is sold, accessibility and other groups like legal, compliance, developers and other types of testing are usually positioned in opposition to the design, because the design has already been fallen in love with, somebody fell in love with the design, lots of people fell in love with it or committed time and money and attention to it. But they did that without consideration of these other teams and the other people that might have to use this experience. So now instead of becoming a yes/and, it becomes a direct opposition. So the design team in some cases too might be finished with their engagement. Their SOW might have been written such as you have got 10 weeks to design a solution to this and hand over the key experience. That positions the in-house team in opposition to the design partner that was hired where someone else has to come in and finish or fix the work that was given. That makes any accessibility feedback or anything else out of scope or it would have to be a change order so that makes it more expensive or it's handed over to a different team again to fix. After all that handoff, there's a big decision to make. Either we can take that design that everybody fell in love with and shoe horn that idea into accessibility, we can figure out how to fix it, we can move this there, change that to this, do the little things that we can do to make it accessible, or there's a perception that we're chipping away at the design.

Then in implementation, this is the worst case where accessibility sees a design for the first time. And this happens all the time. I'm sure like a lot of you attending this session know this and feel this every day. But this is generally like when accessibility will see that design for the first time, remember, like somebody's already fallen in love with it, it's already been validated with users that represented the market of focus and now it's been handed to you in accessibility and it's not accessible for a lot of reasons. It's fundamentally not accessible. This is where all the bad feelings begin. If you didn't have them before. So again, if this is the first time you're experiencing design or seeing the requirements, you, the accessibility professional, have lots of bad feelings about it. And then you want to share what's wrong with this design and the process that led to this design with whomever you can to prevent it from happening again.

And then this is how designers are delivered that feedback. They will literally be given an email, a brief, a list with phrases like oh, with red pen markup, that's not accessible, that won't pass, accessibility won't like that, accessibility rejected your design, do it again, contrast fail, make contrast 7:1, that's too small, I can't make that accessible, that blue is too blue, make it less blue. And all this specific binary pass/fail good bad sorts of feedback. So the opportunity here is how can we include accessibility throughout the process and become mindful of the needs of all users?

So I know that might sound like, yeah, we should do that, like we should always be doing that, right?

Here's some opportunities for us to do that I hope that are -- showing you a picture of the design process again. Engage, discover, design, deliver, implement. In the engage phase I told you some challenges I've experienced in the past with SOWs and RFPs. One thing we can do to improve that is to make sure we create language for all teams to use for those specific artifacts and project kickoffs. One thing we have internally is some boilerplate language that anybody can take so we can make sure our SOWs and RFPs have specific language that says instead of must meet the segment, must be on trend, that we can say must meet our accessibility and inclusion criteria. And I'll talk more about that in just a moment. Then in the discovery phase we can become stakeholders. So anyone that is an accessibility professional or has experience designing for accessibility, you can identify yourself as a stakeholder, make yourself known, and then educate your designers and business peers and you can create ways to test concepts or you can at least help your research team identify how specific experiences can be validated early on if you are heavily limited by your platforms.

Then in the design phase we can create playbooks of examples to help designers learn to draw accessible experiences. In delivery we can evaluate and provide feedback and requirements during the grooming process if you don't do that already. And then in implementation what we can do is we can turn problematic designs into teachable moments. We can establish ourselves as partners and prevent future occurrences. I'll dive a little bit deeper into each one of these. I'm going to share with you a personal example. When I was relatively new to joining Verizon in 2017 we had just started a major rebrand of the my Verizon app which is an app that people use to check how much data they were using and to pay their bill. That was the main two features. It took a lot of work to make that design, the new design accessible, because this design I'm showing here that's very pass actually, I'm showing an image that has lots of different screenshots of lots of different parts of experience, that original design wasn't accessible. It wasn't designed to be accessible. We had done some little hacks to make some important functions accessible, but it was really, really difficult to get it to work. So since we had the opportunity to redesign, we made sure that the design that we currently have and the philosophy and the principles of that design had accessibility in mind. So we partnered with our internal accessibility team to create something that we all felt was universally usable. So the image I'm showing now is also a full screen image with lots of different call outs of very specific moments in the app experience. This is a black and white design system, so that's also sort of easy and lucky for us that those are the brand's colors, black and white and very dark gray. But we had the opportunity to lean into that and make it part of the style, not just do it because that's how we can ensure perfect contrast. We can elevate it. If we need to have large type so that everybody can use it, let's make that like part of the aesthetic, not like, oh, we got to because people need to be able to read and stuff. That's that hohumming attitude. These are attributes and they makeup the personality of the brand and it's something that's able for everyone to use. And I won't say that this design system is perfect. It has lots of problems. We have one example is an over reliance on carousels that we know are problematic. I'm not saying we nailed it and do everything well. But one thing we did do well is start from a base design system and set of design principles that represented a solid set of scaffolding that we could build upon because they themselves, the original elements and components of it were accessible.

So during the engagement phase we can create language to leverage during that phase. So we can define what we mean as an organization, as a team, as a product when you say you're accessible. You can documents that and socialize it so teams can leverage it throughout the design process. This is something we have at Verizon that we co-created with the accessibility team and it's incredibly helpful. We pull this language and reference it in our SOWs and RFPs and it's extremely helpful. That way we can hold ourselves and design partners and vendors accountable for our experiences. So if we do get a piece of design back or a concept that's not accessible or we think might be problematic, we can more easily say hi, partner, please take a look at this. Just remember when you begin an engagement with us, you're committing yourself to create accessible experiences or experiences for everybody to use. I'm showing four different 10ents of those guidelines. We design texts, buttons, navigational elements to the color contrast ratio of 4.5 to one and use visual indicators with interactive elements. Experiences work for customers without vision. We design experiences so that screen readers can properly move through our screens and flows. EG, a numbered list component is laid out in order so a screen reader moves through it, reading in the correct order, one, two, three, four. Experiences work finishing customers with limited mobility. We design inclusive experiences that allow customers with limited motor function to tap and scroll simply and easily. We don't create experiences that rely on sophisticated gestures. I could talk all day about that last statement. But as an application designer, especially like a couple years ago, that was -- that little piece of language won so many internal and external battles for me because I could say look, those gestures, those cool things you saw wherever, that's great. But on whatever app or in whatever trend board, awesome, but if we do that and lean into it, we are literally excluding lots and lots of different types of people, myself included. And it doesn't align with our tenets. And just that, it doesn't align with our tenets or accessibility statement or brand guidelines on accessibility, then that stops the conversation right there. Got it, everyone gets it, and we can move on and start talking about something else. Experiences must work for customers with cognitive, language and auditory challenges. We keep our layout simple and logical, our language easy to understand, our navigation consistent. We only include visuals when necessary and always provide supporting text. This is another one too, just documenting it somewhere that we won't solve it with imagery. That was a huge deal. That was a problem we had in an older version of our brand. Solving it once but making sure we had language to prevent it from occurring again is really helpful. Again, like I'm not saying we did it perfectly or anything, but this is an example of some language we wrote and documented and shared out with all of our partners and vendors and we can reference back to and this helps us work through some common and early challenges. Then you can become a stakeholder during discovery. So at Verizon accessibility is a stakeholder that helps us understand needs and considerations before we commit to anything. Anytime we have an idea of something we think we could work, we make sure to include our accessibility partners. Every design team has an identified accessibility partner and if we don't we know where the central accessibility office is and how to begin that conversation. There's really no excuse to not include accessibility as early as possible. For your org, you may not have that ability or maturity yet in your company's exposure or partnership with accessibility so you might have to start early or create a center of excellence, you might have to create somebody and designate them in a leadership role or write a charter as I showed you in the prior slide and socialize that that defines the discipline or team or tenets. And teach your organization how and when to engage with you. The important thing is overall to establish yourself and establish a relationship and offer yourself as that resource and share feedback at every step that you can. So I have a gif here that I'm showing of Wil Smith, the fresh prince, and DJ jazzy Jeff doing their secret handshake from the classic sit com the fresh prince of Belaire, which was a childhood favorite of mine. And that's the kind of relationship that we should aspire to have with our accessibility partnership at every moment within the design phase to make sure that we're being inclusive. We can also create helpful examples for the designers during the design phase. So the WCAG presents as a space for specialists rather than for designers. It looks like sort of a library sciences website reference kind of place. So often what I've seen in the past is someone will give the designer this link, the WCAG link, or they will give them a copy paste piece of guidance from the WCAG. And it feels so legal and so formal, designers aren't sure what to do about it and kind of approach it fearfully or with intimidation. What we can do to bridge that gap is create some specific examples. I'm showing you a couple of examples of how we define this for the Verizon world, but this doesn't have to be for using your own product as an example. It can be screenshots of anything in the world. But here are just two that we have that are really common. The one on the left of the screen is screens should follow a strict hierarchy and it's an image of a phone customizing screen that's pretty complicated. These are both plausibly complicated on purpose to illustrate how a designer can deal with things that are very complicated but still make them follow a clear order and be accessible.

So the guidance is screens should follow a strict hierarchy, ensure that the purpose of the screen can be easily understood, even when our complex end services are inherently complex because with the products and services we deal with at Verizon, they are the thing itself and acquiring the things are complicated. It's a major purchase. There are a lot of decisions to be made. There are a lot of decisions that our users want to see or interact with all at once. So trying to put those things together and make them easy for everyone to engage with and understand is a challenge, but like as a designer, that is the challenge, that that's the fun and exciting part of design is solving complex problems.

So some specific guidance for that kind of content is all screens need to have a descriptive title. Reading order is top-down, left-to-right. All screens have a strong header style that's a major typographical jump from body to subsection. That's taking some guidance that's our brand and taking that brand and translating into this screen. So major typographical jump between header and body, that's not WCAG language. That's our brand language, but that's an interpretation of both wrapped up together that we co-wrote with our accessibility team. And then all functional copy, that's an internal phrase, is action oriented and instructional and simple. So again, all these pieces of language here, they are not copy pasted from the WCAG, but they were written between the design team and the accessibility team in partnership to help designers understand how to interpret accessibility considerations in a given design system or for a given product.

Then on the right is an example of form elements, because we know form elements are commonly incorrect or just difficult to interact with. So I'm showing a gif of a little bit of a complicated form for us. We don't actually use forms that much. So these form rules are specific to our forms, but overall, keep forms simple, direct and required. So we have an overarching principal just don't have forms if you don't need them. That's not something we usually need. But if you do have to have a form to capture information, forms have to have a title, instructional text to orient the user. The text must meet -- all fields have to have labels, all fields have to have specific descriptive errors. Screen level errors appear at the top and bottom of the screen are persistent in the view. And all fields are required in our form fields. Optional fields are rare and called out with an asterisk. This is our interpretation of the WCAG in our brand, but these we have stacks and stacks of these things to help the in-house designers and any agencies we onboard learn how they might interpret and what they need to consider when they think about accessibility in our brand or for our product or for our users.

So then delivery. When you're in the delivery phase, one of the things we can do better is work with research teams, we can talk through challenges, we can figure out how to validate, create a plan together. I have a gif here of a printer printing out the word test test test test. Lots and lots of testing. I can't stress how much testing enough. We know as much as we can before we push it out to all of our users. What are the limitations of our testing tools?

What considerations can you include in your test?

Is there any way to simulate a screen reader experience and validate it early on?

There are ways to do it, but you can talk to an accessibility professional either in-house or ask someone in the world how you might do that with your particular design. We can consider including participants that would identify as having challenges that might impact their ability to use design. Figure out how to do that in a way that makes sense for your product.

Think about amongst yourselves like what challenges would impact their ability to use. Who would be able to use this?

Who would not be able to use this?

What do you need to do to make sure everyone can use it?

So then use this opportunity finally in delivery to provide feedback on the design. So I have an image here of the meme your design is good, but it can be better from Wonder Woman. You can leave comments on the design, however it's shared with you, but when you do that, as the accessibility professional, make sure that you try to avoid pass/fail language and try to avoid specific solutions. Instead, frame it as a value-add. So instead of maybe saying this color doesn't pass or this link isn't right, and instead of saying make the link underlined, unless you have specific guidance on that, instead try to phrase it as an opportunity this would be a lot more usable if we had two ways of interacting with it or two ways of understanding that this is interactive.

If you have a relationship with the development team, work with them too. Maybe your level of effort as accessibility professional can get added to the overall development LOE and that will shake the tree. Suddenly if LOEs start getting bigger and bigger and bigger and it's because the accessibility effort to write accessibility requirements and test against any given story, if that's considered all together, that will hopefully begin to understand how important it is to prevent that long tail or heavy lift or the larger LOEs at the end of the process by better earlier considerations in the first place.

Z implementation. So we can coach, we can reject, we can partner and power through. This is when you're all the way at the end and the first time you see the design and it's not accessible. You can design. That's your moment to say I can, depending upon where you work and who you work with, you can coach the people that created that design on how to work with you to make it better the next time. You can reject the design. That might be a tactic that's really effective where you work. Or you can partner and offer to do it together the next time. That might be more work for you. It probably is. And it may not be the right thing for your team, your culture, your product, but you have got to experiment with those kinds of tactics and figure out what will work for your team and for your designers so that the people that you work with can begin to internalize the needs of all of your users and be more mindful on future projects. And then repeat that. User experience designers or designers should get it. Once you bring them on board or make them mindful and show them the opportunities to be inclusive. They should get it. But not Nemeth's. That's an assumption. And not necessarily everybody on the team will empathize or trained to empathize or simulate empathy. So when you do partner with a designer and educate them, you'll build new advocates and hopefully future designs will become more usable for the end user and less painful to create.

So in summary, designers forget, trends are often inconsiderate, the process isn't inclusive, but you can educate, you can partner and you can create new advocates and hopefully make the process easier for everybody and more inclusive.

Here's some references. This will be provided on the site. I think a lot of you here don't necessarily need these references but I've also got some Verizon team shout out stuff in here too. Yeah, I'm excited to hear what if any questions you might have and I hope that was helpful to anyone.

>> Great!

Thank you so much, Brandy. And definitely just judging by some of the comments here, not only was your presentation very practical to apply, but also very relatable. We have a lot of people saying gosh, this is me, this is my job. And I wish we could have another hour in this presentation is one of our comments here. We only have a couple of minutes so I want to make sure that we at least get one question  in.

>> Do I stop sharing or no?

>> You can keep the slides up.

>> Okay.

>> So this person asked:  You mention that envision makes it difficult to test something like a modal dialogue with the screen reader early on in the design phase. Are there other more accessible tools you would recommend using for testing designs?

>> No. That's like the challenge. So we're still in a position where we really have to rely a lot, like way too much, on gut and working with our accessibility team to just build off what we know to be true today and what's problematic today and what we know isn't. For our end, that keeps us safer in our designs and like prevents us from experimenting more, which is kind of a bummer. So we err on the side of safety. But if we were to pick up something that we know is going to mess around with something we think is going to be a gray area, this is coming up for me now, actually. We are going to mess around with some modalities that might be challenging, we are going to do have to work on a way to simulate it and test it specifically for AT users, because that's who, for that particular thing, that's who really would have the hardest time with it. Anybody who has color perception or low sighted challenges or dexterity challenges should still be able to use it because it's already accounting for the nature -- we have to find a way early on to validate that we can make it work. We might even have to go build it, like build and experiment and test the experiment.

But low fidelity, like paper prototyping, there's a lot of very experimental ways of testing those, but yeah, not using a broadly available platform liken vision or Marvel or Figma.

>> Awesome. Thank you for that. Looks like we're actually over time a little bit so sorry for those whose questions we didn't get to. Thank you so much for your great engagement and thank you, Brandy, for your presentation. I think everybody enjoyed it.

>> Yeah, if you have questions for me in real life, feel free to find me in real life and ask me.

>> Awesome. All right. Well, everybody please enjoy the rest of Axe-Con and have a wonderful rest of your night.

>> Thanks.

>> Okay it's now 4:30 Eastern Time so we are going to go ahead and get started. Hi everybody, my name is Laura Goslin. I work at Deque and I'm going to be moderating today's session, auditing design systems for accessibility brought to you by Anna Cook. She's a senior product designer. I'm going to take care of a few housekeeping things. Just a reminder, the slides are at the bottom of today's event session page if you would like to follow along with some accessible  slides. Second, we have captions underneath the video for today. And then third, we are going to try to save the last 10 minutes or so for questions so feel free to put those in the SLIDO Q&A feature and I'll be sure to ask those to Anna. With that, I'm going to go ahead and pass it over to Anna to kick us off.

>> Hi everyone and welcome to auditing design systems for accessibility. My name is Anna emptCook and I'm so happy to join you virtually today. I I couldn't be more honored to join this group of speakers. I'm so excited to get started but first I'll tell you just a little bit about myself. As I mentioned my name is Anna. I use the pronouns she/her or they them. As senior product designer at recurly. As product designer my job is to design applications and websites, test those designs with users and prepare the most robust systems to be implemented in code. I'm a student at the Atlas Institute of CU  boulder. In my free time I'm an artist, gamer and writer. I have two adorable cats named Phoenix and onyx shown here. You may see or hear one or both of them running around in my background today. They like to speak when I speak sometimes so just be aware. What are we going to focus on today?

Over the past 8 years of my career learning about inclusive design has been fettered with blockers and educational gaps. It's my intention to help unblock designers, and tech folks who want to -- especially my fellow designers about where we need to come in for accessibility considerations. But since we can't cover it all in 50 minutes I will focus on what I believe to be the most Pivotal accessibility works -- in particular we'll focus on learning how to find accessibility issues in your existing design system and documenting those issues in a way that makes them actionable for you and your team. Let's start with a little background on design systems. What exactly is a design system?

A design system is a single source of truth for our product, site or experience. These include a shared purpose and a set of values for  design/development organization as well as brand elements and component pieces. Design systems group related implementation elements together, define their purpose and clarify their therefore. When done correctly a design system should evolve and scale with an organization. These systems are important because they enable us to work at scale, do something once and apply it everywhere and establish a more consistent brand but most importantly to our conversation today, a design system is essential because it scales accessibility as well. In this session's description I mentioned that each atom, molecule and organism we create in our system affects our ability to scale upward and meet disabled people's needs. My mention of atoms, molecules and organisms is a direct reference to Brad Frost's atomic design. When atomic design was released a little over four years ago it marked a Pivotal shift in design thinking in digital  landscapes. Though many teams had already begun to -- blitz wrap, atomic design had -- digital design needed better systems. Four years later Brad Frost's book is still quoted regularly when design teams make the case for design systems. For our session we can use this methodology to help inform how to design accessibility at scale and audit our systems for accessibility compliance. In atomic design Brad Frost breaks down the scale of design systems using anatomic approach. Our -- elements such as atoms which can be combined to create molecules and can be combined to form  organisms. These organisms form and scale to create templates that can then apply to specific pages in our platforms. Each team has a slightly different understanding or jargon around this scale but these elements tend to carry consistently through most digital design systems. You don't have to have a robust or perfect design system to use this methodology or audit for accessibility. What we are going to talk about today can be applied at any point in your design system's development regardless of whether your team is just starting out or already has a well documented usable system. Let's start by breaking down how atomic design tends to scale. I will create examples of interfaces similar to those I've audited at recurly with my team. Before I move to atoms, let's talk about subatomic particles. Bear with me, I'm not a scientist and I'm definitely stretching this atomic design analogy just a little bit but essentially these are the foundational elements that carry up to our design system. They aren't atoms but they inform the creation of atoms. These subatomic particles tend to be things like brand colors or typefaces and while these elements alone may not seem the most important for our system, they will affect all of the elements we create from our smallest scale to our full blown pages. I'll ask you to keep  subTomics in the back of your mind as we move forward. Moving into our atomic scale. Atoms demonstrate all the base items at a glance which can be a helpful references to come back to as you develop and maintain your design system. Some systems have greater granularity than others so it's important to be mindful that words like atoms in this context can sometimes mean different things to different people. For our purposes atoms are elements such as form labels, inputs and buttons and other things that can't be broken out any further without ceasing to be functional. Using our example UI, I've put together an example -- but like atoms in the natural world, interface atoms don't exist in a vacuum and only really come to life with application. In our next step in the atomic scale, molecules are relatively simple groups of UI elements or atoms functioning together as a unit. For example, a form label, dropdown selector and save button can now be a functional form field event. When combined these abstract items suddenly have a purpose. Now we can create a purposeful interface by combining these elements. Selecting the button atom now saves the dropdown input and the label indicates it is purpose of the input. That can be dropped anywhere a dropdown input or save form is needed. Scaling up again, organisms are relatively complex UI components composed of groups of molecules and/or atoms and even other organisms. These organisms form distinct sections of an interface. Building -- provides designers and developers with an essential sense of context. Organisms demonstrate those smaller simpler components in action and serve as distinct patterns that can be used repeatedly. For our purposes we've taken our dropdown/save form and applied it to a specific context, in this case a currency selection. This organism is also made up of other atoms and molecules and serves a more specific purpose. Moving away from our analogy, we can use our atoms, molecules and organisms to create templates and pages. Templates are page level objects that place components into a layout and articulate the design's underlying content structure. If you find you're reusing the structure of a page for a lot of different applications, you can use that template for other pages. A template displays all the necessary page components functioning  together, providing context for our relatively abstract molecules and organisms. By defining a page's template we can create a system that can account for a variety of dynamic content all while providing needed guardrails for the types of content that populate certain design patterns. finally, pages are specific instances of templates that show what an experience looks like with real representative content in place. In addition to demonstrating the final interface as your users will see it, pages are essential for the effectiveness of underlying design system elements. It is at the page level that we're able to take a look at how all the patterns hold up when real content is applied to the design system. We've taken our atoms, put them into a molecule, bundled the atoms and molecules to create an organism and applied them to a page or template. These are the atomic design principles that have made our design systems thrive. A well scaled design system can make it infinitely easier to ideate around a user's need and make your workflow highly effective. Pretty easy, right?

Wait!

Hold up!

Atomic design's excellent, don't get me wrong. Did some of you notice some of the issues we -- when we created this example interface we weren't thinking about accessibility. We were just thinking about the design system. And doing this can have implications on the entire system. So let's take a step back to understand some of those implications. I've taken our example page from earlier and marked it up with a set of things I've noticed right off the bat that need attention. Because we use these atoms, molecules and organisms without thinking about accessibility, we have got elements with accessibility concerns and issues baked in all over the page. We have got multiple elements on the page with too little  contrast, a lack of clarity about what form fields are required, no clarity on -- there could be more than this list alone but we can notice these accessibility issues on our system when we start to audit them. Auditing both pages can be a little overwhelming especially when issues are related to a component's inherent design. This initial sweep of this page has shown us a handful of issues, many of them related to others. How about we break this back down using our atomic approach and focusing on one of these atoms. I'm going to take us back to the very beginning, before we made a molecule we had our atoms. But I'm not going to -- page's accessibility by beginning with one atom, our button. Our example button design may have a few shortcomings but to keep it simple, let's focus on how it didn't meet color contrast compliance. This relates back not only to our atom but our  subTomics and our textiles and color options. This is part of why I mentioned to keep that in the back of your mind. At the very beginning we talked about the foundational elements and how they can affect these designs. Now we can see the ramifications of using those foundations to create atoms without accessibility in mind. For example, our button here has used a green color in its background and white text on top. Our text is 14 pixels and semi-bold weight. We test this using the stark plug in or any color contrast checker, we can see the button doesn't meet color contrast requirements. This combination of colors has a ratio of 3.21, but with a 14 pixel semi-bold font style, the contrast needs to be 4.51 to pass the minimum required level. As we discussed, this combination of colors is going to affect more than this component. We know there's an issue with the component and we know it's going to affect others because its problem is foundational. This is where our auditing really starts to come into play. Such issues like the ones we've encountered are why design needs to be thinking about accessibility, particularly with design systems. There's a misconception in design communities that accessibility tends to be mostly developers' responsibility but developers can't fix design issues when they're design centric. In fact, a Deque case study from last year found that 67% of accessibility issues originate in design. If fixing accessibility issues can amplify time and money spent if not addressed early and often. No pressure but there's a lot of responsibility on our shoulders to create accessible designs. Prioritizing accessibility in each system can save a lot of time and money. When applied in a broad scale through our design system, things like strong color contrast can cause sweeping accessibility improvement in our products. Enough about why. Let's talk about how. The easiest time to review your designs for accessibility compliance is before they are developed but that's not always how it goes. Many of us work on design systems with a combination of live components, inflight components and even components that are live but undocumented in our design files. The starting steps of an accessibility audit for your design system look the same as a standard component audit. We want to review our components which are being most actively used to create designs and document what exists. We don't have to start thinking about accessibility just yet. The intent will be to document what exists and gather elements with similar purposes together.

For our purposes, I'll focus on some example buttons for our audit. Your team may want to do a  holistic design -- you may find that existing design components include atoms, molecules and organisms. It's important to capture all of these as well as noting their intended purposes. Now, you don't have to write up full documentation or anything like that just yet. Just a note will do. In a screenshot I've included here, we have got a set of buttons from our recurly experience as well as a note about their intended purposes. As a call out, we've noted the intended purposes are not based on things such as colors like green or blue but instead purposes like primary call to action or destructive state.  Similarly, we are going to want to capture all live components. That is to say all components that exist in any existing pattern libraries such as what I have got pulled up from story book as well as components that may not exist in your design files or pattern libraries. This should also include such things as different interaction states like hover or focus. Again, the purpose of capturing these components is to audit the system itself first and what exists. We don't need to start looking specifically at accessibility issues in design or in code until we have got a solid frame of reference for what users are currently interacting with. The design system audit itself can take a little time and it's not always going to be perfect so keep that in mind. Our team member recurly went about -- via screenshot and then uploading it into an inventory file in thinking mawith the date, time and location. Each item that was captured was placed in a page named by purpose. In the screenshot here, I'm on the button page. What I've captured here looks pretty similar to what we had in our source design but in other cases we found variants of components that we didn't know existed or didn't have in our design system libraries yet. When we started capturing what is live we can cross-reference this with our design team and start to see where gaps exist. You might be thinking just auditing your design system isn't going to help with accessibility but as I mentioned earlier the best starting point to scale accessibility is within an effective design system. We need our design system to be audited and scaled and be powered to scale accessibility. These practices should go hand in hand. Since everything we discussed -- directly into auditing accessibility, let's talk about what we need to be reviewing for accessibility compliance as well as how.

What should we be auditing design-wise?

Well, as we talked about earlier 67% of accessibility issues start in design. So maybe more than we realized. There are many items outlined in the Web Content Accessibility Guidelines and many of them relate to design just as much as they do development. Even though our earlier example was focused on a common example of accessibility in digital design, there's a lot more than color contrast that we need to keep in mind. Some other accessibility requirements that need to be outlined in design include color  usage, content strategy, heading structure, link behaviors, hover and focus states, form behaviors, and everything else on this list as well as more. When we got a set of components outlined by purpose in Figma, it's easier for us to look past UI and see into the other accessibility needs. Now we can look at our atoms, molecules and organisms according to their purpose and styling, which will help us address more than the surface issues because while UIAccessibility does matter, one of the reasons designers tend to think our responsibility to accessibility is focused mostly on color and type, it's because we don't realize how closely tied UX is to accessibility. So let's look at some examples of how we can audit past our styling alone. This example alert is designed to have a set of different types of messages:  Success, warning, information and error. There are a couple of UX items we can investigate with this alert. For example, we can ask ourselves should these icons have alternative text or Alt text?

Let's say these icons don't currently have Alt text but we think they should because we don't want this icon to qua-- we want this icon to convey an alert tone to users who may not see the color or may not see the icon. So in our accessibility audit, we can note there's no Alt text being used for these icons and relate it to world content accessibility guideline 1.1.1, non-text content. If we're using these icons elsewhere with similar purposes this note in our audited will help us scale this UX element to many different instances. Or let's say our error alert shows multiple errors in one alert container. We will need to ask if this alert is clearly identifying what errors need to be fixed, where the errors are and how they can be fixed. If our alert doesn't do these things, we can note this issue and relate it to  WCAG3.3.1, error identification. These are some of the questions that we as designers can and should be asking ourselves when looking at our existing components and building new ones. If we had these components lined up together and a reference for their context, it can be easier for us to understand potential accessibility gaps and add them to our  audit. And by the way, this is why I tend to talk about accessibility the same way I talk about design in general. You may have noticed that as I talk through some of these items we would want to audit on a component like this, that it felt quite similar to your standard design system thinking. That's because it is. Accessibility is just a form of design that requires discussion and testing the way all design does. It's about making sure our designs are accessible with disabled people's needs. When you're auditing for accessibility, you can use WCAG as a guide into user feedback to see what needs -- another thing about our design system audit is we should be reviewing both designs and code for accessibility.  Now, I know some designers may cringe at the idea of reviewing code for accessibility issues, but we don't have to be developers to audit code. There are many code that enable us to audit code on pages or specific components. And since we're here at Axe-Con, I'll call out the axe plug in. Using this tool, you can run both automated tests as well as guided manual tests to do a thorough review of your design code. At this point I've talked a lot about what a design system is and what to look for in a design system accessibility audit but I have not given you insight on how to document an audit. I know I've alluded to adding things to our audit a few times, but what does that actually look like?

Let me show you. By the way, this is where I diverge from my script so you'll start to hear more ums as I go through this. I'm going to open up links here and talk through what these are and put my glasses on because I'm looking more closely. There's my mouse. I have got three things I've pulled up here. The first is the ant design system. I pulled this up because it's a live component system that I can access and show you in context. We'll talk a little bit about this one in a moment. The next thing I pulled up is a spreadsheet, a Google sheet in this case and that is where I'm going to put my [Away from mic] information. We have got a couple of things to keep in mind. Any accessibility audit, regardless of whether it's your design system, code, page or anything like that, requires you to start by building a background. And by background, let me explain what that means. Essentially what I've outlined here and I've included it at a high-level. You may find you want more or less detail. Essentially it's who's reviewing it, me, a summary of what we're reviewing as well as what level of accessibility we're looking to meet. That is for our purposes today, WCAG2.1. Scope of review, in our case it's the button in the ant design system. URL or set of URLs. Time line is just today so we only have today but you may find it's a span of time. And then the review process, outlining that so people understand exactly what went into the process, especially if they are going to be looking at this later and going, oh, okay, so this is what Anna did when she was reviewing this, these are the pages she reviewed, this is why this button looks this way and not that way. The background is super important even though you're not personally referencing it a lot just for the sake of knowing when it was taken and how. The last thing I'll mention before I actually show you the audit, I'm going to talk about WCAG. I personally am a huge fan when I'm auditing of having WCAG's quick reference guide. I like this tool a lot because you have got your side bar navigation with a bunch of anchor links and you can jump between sections and link to specific items if you wanted to talk about them specifically. So we'll talk about that in a moment and what that means, but I like this tool a  lot. It's also super helpful when I'm doing manual auditing and I need to remember certain logistics and details like what is -- gosh, what is a good way to use color, for example. Super helpful tool for any audit. We may not use it too much today but I always have it open when I'm auditing. And I use it pretty much three or four times a day anyway. Taking a step back.

We have got what we're auditing today. It's ant design system. What I'm going to do here is walk you through my process. Again, it's not a perfect process. Feel free to adjust and tinker with it as you see fit. I'm going to use X to get myself started. I'm in Chrome. I'm going to select inspect. My inspector opens and I'm going to select the axe dev tools. Maybe I'm not signed in. It should be signed in. Maybe not. It wouldn't be a conference if I didn't have some technical difficulties, of course. There we are. Perfect!

Going back so I can talk through that before I got flustered. I got my inspect, selected Axe, for our component audit we are going to select scan part of my page. Axe allows you to do all of the page or part of the page, but since we're only reviewing a button component we don't need to scan the full page. We could scan the full page but we could get flagged for navigation issues or things like that. So just focusing on one part of the page is enough for us. I'm going to select what part of the page I want to audit and click scan.

I have five automated issues that pull up. All of them are review issues, which means Axe doesn't know if they need me to make sure they are real issues because of some way it's been coded or how it appears but we have five issues all of them related to color contrast. Axe will find things like lack of landmarks or tab index or any myriad accessibility issues but for our purposes we'll focus on color contrast. I'm going to highlight specifically the first issue that comes up and that's going to be our primary button. So Axe will highlight exactly what it's talking about and show me exactly what it means. Since I've already done this, I already know this issue does exist so I'm going to save the result and come back.

Say it is an issue so we can talk about what that means. There's a few things that are really helpful here. I've saved the issue. If I wanted to I could use Axe to export that issue as a CSD or J son files. Highlighting the issue again, Axe will tell me what exactly the issue is by selecting more info and I can find out exactly what it's being flagged for, what WCAG item is related to that and the user impact of the issue. Now, again, I know this doesn't pass color contrast because I double checked earlier, but let's talk about that. How do we enter that into the spreadsheet?

We have got a few things. And again, Axe is going to allow you to export an issue with a lot more than this if you want, but here's the basic elements I tend to use in an audit. We have got our component, the primary button. The WCAG principle it's related to that is perceivable of our principles. The WCAG guideline that it relates to, 1.4.3, contrast minimum, level AA. I've also linked to that quick reference guide here so my stakeholder can understand exactly what I'm referring to with this audit. Additionally, I've described the issue in detail and why it exists for our stakeholders. So in this case WCAG 2.1 level acquires a contrast ratio of 4.51 for normal text. The text on the primary button is 14 pixels with a normal weight, meaning it doesn't pass color contrast compliance because the foreground color is white, the background is light blue and that means the ratio is only 4 at any time 24. The -- detail as necessary and it pairs nicely with the recommendation. This one's more what I tend to include but it just helps stakeholders understand how actionable an item is. So I'll say increase the contrast between foreground and background. Now, you can do this in a set of different ways and it really depends on what the design team wants to do but you know that's what you need to do. I've also got impact. I flagged this earlier because Axe lets you see the user impact. Impact is a little bit of a sliding scale in terms of perception. Axe flags it according to user impact. You may choose to flag impact according to business or fiscal reasoning or how often a component appears in your application or any combination of those things along with user impact. It's really up to you, your organization and your team. For our purposes I marked our impact as serious. There's also critical, moderate, minor, best practices and unknown. Unknown being things like is this the right use of aurya, let me make sure with my team. I want to be sure. I've also included the URL and the date it was created. Almost exactly the day. I'm off by about two minutes. Essentially I would go through every issue, both automated and manual, add each issue as a row item in the spreadsheet, and document that in detail. Again, Axe would also export all of these issues for you with more detail if you would like. I have found that to be helpful in the past. Doing it manually like this is also okay. What matters most is that you're creating a system that can be used and referenced later. So that's a high-level of what our audit looks like. It's obviously a lot to take in. I have a few things to call out with my approach before I wrap up. First off, I would love to talk about it all day. I'm sure there are many places where I can help share what my thinking is around  this, but I shared this today because I want you to see my process and adapt it. In fact, I encourage you to diverge from my approach to find auditing that works best for you and your team. What matters most is that you're trying to document issues in a way that makes them actionable and so that your organization or team can act accordingly. If you're using Axe, you can export those findings as I'm showing here and fine tune the details based on your organization's needs. Secondly, I want to mention that when you're sharing results I recommend grouping themes of commonly occurring items together. This touches back on our atomic scale. If that primary button blue contrast ratio issue was occurring on a lot of different items, what I could do is essentially say this is related to these set of issues. If we just change the hex code related to the token or adjust it just a little bit or changed the font size a little bit for all of these, then we could fix this issue. So grouping and -- especially for your design system audit is super, super important because it means you're going to be able to have a much higher impact without having to do a lot of fine tuning in a lot of different places. It's more of like that power of design system right in one spot. A big change with a little amount of effort having a huge impact. So we're looking at that green color we had earlier and that white color combination. These are some items related to that in that audit at recurly. You can see how easy it is now when looking at them together to fix them together. Another mention I need to make here is that you will likely find you don't capture everything that needs to be captured when auditing your design system alone. And really it's because we tend to work in complex systems and a design system's all about intent. There's always going to be circumstances where what you capture in your audit and fix doesn't fix your design system's application. So maybe your atoms are amazing and accessible but your organisms need more attention because they're more unique to specific circumstances. So this is part of why I went through our atomic  scale, to help us understand that there's a difference between intent and application. Starting with the design system's going to get us super far but it's not going to fix everything on your live site necessarily because the application is different. Okay, so let's say you finish your audit or part of the audit. What should come next?

Yes, that spreadsheet with a list of items and specific relation to those items being itemized is going to be super essential, but we want to empower our teams with those findings. Getting handed a spreadsheet with tens of possibly hundreds of items absolutely helps when going to fix something but it's going to be intimidating if you hand a stakeholder a spreadsheet and go here you go. What do we do with this?

Here's an example of an audit share I did with a client where I outlined the most commonly issued items and themes as well as the high impact items. So when we wrap up our audit we can make sure we present everything we discovered but at a high-level. That is we need to outline what is most critical to fix and key items, then share an impact framework to help identify which issues can be fixed most quickly with the highest impact. Putting these together along with our complete audit means we can share results in a digestible way and work with shareholders to prioritize improvements. No matter how comfortable you are with accessibility, I would encourage you to stay curious. Many designers are not trained in accessibility and that's on educational institutions, not you. The fact that you're interested and learning is a huge step so if you're starting out, download apps, open WCAG's quick reference and play around, document things you're finding, ask yourself  questions, ask your team questions. Just playing around with these tools and scanning these guidelines and being curious is going to take you so far. Honestly, much of my accessibility knowledge has come from those practices.

To come to time for questions, I want to mention one last thing here. One of the most essential aspects of accessible design is designing with disabled people instead of for disabled people. WCAG is written with and by disabled people. So it's great to use in an audit, but is it everything?

No. Like all design, accessibility requires us to talk to people and learn about their unique circumstances, especially when using our sites and products. While I can't advise a perfect inclusive research strategy with the time we have left, I want to call this out because I don't want anyone to think that an audit is everything about accessible design. It's a key component but we need to continually hear and respect the needs of disabled users and people.

I encourage you to take the insights from your audits, find ways to ask users what they think, test your ideas, and pay particular attention with your marginalized users. Last and certainly not least, I would like to give a shout out to my team at recurly for helping me with this presentation. One of the things our product team believes is striving for accessibility should be about innovating. We hope by sharing this process with you we can empower your teams to make amazing, inclusive and innovative work. With that, I'm ready to open our time for questions.

>> Awesome. Really great job, Anna. You had some amazing content in there. And the chat is just loving what you presented so far. And because of that we have some questions for you.

>> Great!

>> Let me pick out one here. So how do you and your design team define interaction expectations when the components could be used in a multitude of different use cases and contexts?

>> So breaking down those interactive explorations and context, I think it's all about what that context does for our users. So recently we went through the process of defining a new component in our system and we needed to define different contexts for that and those interactions. We would be specific about things particularly when it came to different ways of communicating information. That is to  say -- let's go back to our alert, for example. We would want to define how the interactive -- how it would be interactive when it came to what kind of message was there, for example. We would define the core elements of the component and then diverge as necessary according to the variations of that component. So let's say we have our error component versus a success component. Should we be using aurya polite or aurya aggressive I think is the word I'm looking for here. So we would diverge as necessary to help define that context for each component. And then each component's going to have some variation or specifications according to that context. We'll also find that a component will have one sole element and we can treat it a certain way like how should we treat our close button on the alert component, for example. That can be defined once instead of diverged.

>> Perfect. Great answer. Another question here. I think specific just to design and accessibility. How do you make disabled buttons accessible?

They usually look faded and the colors do not pass color contrast.

>> This is a really good question. And it's like the eternal conversation with accessibility in design. Because technically your disable buttons, according to WCAG, disable buttons don't have to meet color contrast compliance. However, disabled states have a myriad of usability issues in and of themselves. Yes, you can use disabled states and have them have lower contrast, but what are the ramifications of using that disabled state?

Why are we using it?

If it's for -- it's always a question of are we using this because it's easier?

Are we showing users they can use this  eventually?

Do they know how to use this eventually?

So the short answer is technically you can use disabled states. The long answer is disabled states have a huge set of usability concerns that aren't necessarily captured in WCAG and so as a general rule you want to avoid using them if you don't have to use them.

>> Great. Someone is asking if you could expand on how you prioritize which issues to fix first.

>> Yeah, absolutely. So a couple of things I will look at when doing an audit. When I'm doing an accessibility, especially a component audit, I tend to look at core elements first. That is items I know are going to be occurring throughout an experience most commonly. That's things like our links, heading structure, our buttons, our form fields. Those core elements that I know are going to be reused the most regularly or I'm seeing being reused are ones I will reference as higher impact. I also will look at things like if I'm seeing -- like that color contrast example for example, if it's being used in a lot of different places, I'll flag that issue and make it a higher impact issue because I know it's easier for us to fix while having a huge swath of things that are being addressed at once. So I'll look at it that way as  well. There's also things like is this blocking your user from doing an essential task. So like higher impact items definitely, I will label something as higher impact, excuse me, when it's like this form field has to be input to register for our site, so we can't have the label be wrong or can't have it not read to screen readers because otherwise the person doesn't know what's happening. So I'll look at those things as well. Additionally, I will also, when assessing impact, will look at -- I'm losing my train of thought, excuse me -- what level of compliance we're wanting to meet. If my organization or an organization I'm working with wants to meet AA compliance and that's their threshold, I will tend to log things that are AAA compliance issues as best practices or minor issues just because I still want them to know that they would be better to do things that way. Those are things I tend to look for most. And again, like if you find that registration form field, for example, that's going to have huge fiscal impacts, user impacts, business impacts, that means it's going to be critical to fix something like that. So it comes down to what you are assessing as high impact in terms of your user experience in general  too. And most importantly, if I get the chance to talk to users, I'm listening to what they have to say. For example, I had a set of users talk about the date picker as an issue for a component recently and that's notoriously tricky to use so I put that as a critical issue. Screen reader users, excuse me, I should have been clear there.

>> That was a really great answer. This is another good question. Do you include leadership buy-in when you're choosing that prioritization to correct what you find on the audit before doing it?

>> Yes, usually what I will do is put the spreadsheet together. I'll make sure leadership understands what I found and what I'm flagging as the most critical and talk to them about what has been found and how they want to assess that priority. Because I am an individual contributor so my insights on to certain things might be different than someone who's at C-Suite or leadership. So my hope -- I always want to make sure they're bought in, not just because I have to, but because it helps them learn and it helps them ingrain this in their practice going forward.

>> Yeah, that's a really, really good point. Kind of switching gears here, someone is asking how often do you audit your product?

 

>> That's a great question because I think auditing the way I described it today, like a full system audit, you don't necessarily find yourself doing that all the time, like fully. But auditing components or auditing pieces or auditing pages, that's happening all the time. And it should be because that's how accessibility should be. Anytime I'm looking at an existing component and asking how it's built, I'm looking to make sure auditing it, both automated and manual auditing. If I'm looking at a page and making sure it's screen reader accessible, I'll be auditing that page. Personally, I find I'm doing a lot of auditing even just to answer my own questions as I go through and learn, but I also tend to flag things, especially like if I find there's a recurring issue I'll try to flag it and note it.

>> Great. Thanks for that. Looks like we got a question here. How do you close the loop?

After your audit is done and you find the  defects, how do you make sure that the engineering team is fixing those, and that they're actually correctly fixing those?

>> That's a great question. It depends on how your team is structured, I think. You might have a design system team that is nuclear or like a single team that's focusing on it. And you'll be more likely to have a team like that to be really dedicated to making sure. Or you might find you have a spread of Scrum teams within a product organization where each of them is contributing to a system and making sure a component is well built and accessible. I tend to  find -- you want to make sure that you're including, you know, clear documentation. Having accessibility considerations in your component documentation's key. I tend to reference IBM's Carbon a lot for this purpose because they do a good job of that. There's a myriad of design systems that do a great job of it. I would reference something like that, making documentation that includes accessibility considerations. Having constant conversations and not to the point of everyone having meetings all day, but having a conversation is huge here because there are things I don't understand. And like the other day I talked to the developer on a project I was working with and asked them about should we be using aurya here, what ARIA should we be using here and what do you think. It's like UX in and of itself. It's going to require conversation to make sure it's being done right and I would usually look at it that way. Also having accessibility in your acceptance criteria if you're building something within a feature, that's super important. Making sure your QA team is aware of it and finding a way to test it yourself or with QA. Those are going to be huge too.

>> Great. And I think that's a really good note to end on. We're also at the end of time. I want to thank you, Anna. You did such a great job. The chat has been super engaged. Anna, you're very active on Twitter so if folks can get their questions answered, it's probably a good idea to follow you there. I want to thank you again and thanks to everybody who joined us here today and hope you have a good rest of your Axe-Con.

>> Thanks everyone.

 

Agile, Educational and Empathetic: a Digital Persona Set Linked to User Journeys Serving Accessibility

Type: Breakout

Track: Design

You already know about personae even in the field of accessibility. Supporting creativity, these archetypes of users also prove to be invaluable for bringing use cases to life and for embodying testers with disabilities. This is the challenge of our set which is fully integrated into the agile approach. Each of our personae is directly linked to a guideline base, user stories, and the corresponding acceptance criteria. The Product Owner thus has all the tools in hand to provide users with an accessible digital experience.

 

Hi, everyone.  Thanks for joining.  If you are looking for the agile educational session, you are in the right place.  We are waiting for a few people to get started.  

I think test time to get started.  Hi name is Grace Kirkly from the Deque team and I'm excited to be moderating today's session tight the, agile, educational and empathetic, digital personalinged to user journeys serving accessibility.  Presenting today will be Nathalie Pican and Vincent Aniort from Orange.  I'll go over a few housekeeping items beforehanding things over.  The session is being recordedend you'll be able to watch the session on demand if you come back to the presentation page you're on now later today or tomorrow.  Live captions are available below the video screen.  Finally, we'll save the last ten minutes or so of today's session for Q&A.  So please post your questions in the Slido Q&A next to the chat which is also located beside this video stream.  And I recommend sorting your chat by "recent" so you can see comments scroll dynamically as they are input.  With that, I will turn things over to our presenters.  

>> VINCENT ANIORT:  Okay, thank you.  I'm Vincent Aniort.  I focus on agile and educational how they're linked to journeys, serving accessibility.  My talking points are who are we?  Who is a persona and what is it for?  How are personas used in the field of accessibility?  Why did we want to create persona set?  How is our persona set designed?  How can you navigate between personas and other tools?  

First of all, when who are we?  We work for Orange.  We have around 180,000 employees worldwide.  You must know that Orange is invested in digital inclusion.  Orange has a department since 2005 called EASE for eAccessibility solutions for everyone.  

Who are we?  First of all, we give training.  We have awareness sessions to course, project owner, designer, et cetera.  All training sessions are also available in eLearning.  We also provide accessibility in every Orange design.  Accessibility guidelines, we explain in WCAG.  Front end framework known as bootstrap called it Orange boosted.  Digital project themes can apply and accessibility criteria on their own.  And, of course, a team of accessibility experts, we support a team over the life of a project and accessibility audits.  

 

We created the accessibility statement for our websites and mobile apps.  But let's talk about the French on the next slide.  French and European accessibility laws what are they?  First of all, we have Europe directive on accessibility and websites.  The law for digital content to be accessibility and accessible means WCAG 2.1 double A.  It was transcribed to a French title.  

This has been extended to companies with a turnover of more than 250 million euros so around one of these.  It's pretty huge internet, extranet, intranet sites.  Mobile apps, digital docs, audio and video files, software packages.  That line is July 2021 to write for each site an accessibility statement.  We have three more years to be definitively accessible.  

You can easily understand that it's going to be a hard year, and a busy year with this kind of deadline.  Next slide.  

 

>> NATHALIE PICAN:  Thank you for those introductions.  Let's get into the bare bones of the topics.  To begin, what is a persona?  A persona is not a real person.  It's an architect of user, of a product, a service built from real data, mainly from interviews, and service.  It was Allen Cooper, 1999, who first suggest the concept of user character in software design.  

What does persona mean.  Keeping the whole target in mind.  Stimulating creativity.  By using a narrative pictures and name, a persona provides designer with vivid representations of the target.  It helps to get realistic idea of users throughout the design process to make decisions about product features, navigations, interactions, visual design, and much more.  

To prioritize the design work understanding what the user needs and what functions are nice to add and have.  How are personas used in the field of accessibility?  Next slide.  We study various elements of personas on more particularly on accessibility.  We found several studies using personas to work with on people with disabilities.  For example, we created a group of personas for everyone.  The website, story of people with disabilities using the web to highlight the effect of accessibility buyers on the broader benefits of accessible website on web talks.  

Creating personas for people with disabilities can be invariable on accessible product.  Accessibility personas identify the barriers, frustrations and common issues that people with disabilities face when using inaccessible product and often result in benefits of all users.  Next slide.  

 

 

Why did we want to create persona's set?  The creation of persona set accessing accessibility had several objectives.  We wanted to create empathy for people with disabilities.  We would like inquiries to understand that their disabled colleagues are just like them.  They have a life, a family.  First of all, all of us could be temporarily disabled.  

We all have concern with accessibility and we all have a role to play.  Digital accessibility is not only for specialists, but inverse, everyone.  For example, you have to follow a few simple rules.  With personas, we provide access to these rules.  Second objectives.  We do a lot of accessibility training.  When you can involve the person with a disability, students immediately pay much more attention.  But it's difficult to find people who are willing to testify, so personas can help us with this.  

Third objective.  We also wanted to find a solution to implement recommendations for getting accessibility.  They need to understand why these recommendations are important.  And we need to help them to integrate them into their project.  

Finally, we regularly carry out technical audits.  When presenting the report, referring to a persona, hence, to appropriately illustrate a program.  Next slide.  

 

 

How a persona is set consists of ten individuals.  The more specific we make our personas, the more effective the design.  So we have six men and four women ranging in age from 23 to 70.  Six work at Orange like manager, UX designer, technicians.  And four are Orange customers.  

Some live in a big city.  Others in the countryside.  Some are married, and have children, or they live alone.  An objective was to represent the disabilities that could cause a digital accessibility problem.  Visually impaired.  Angelique is blind and Marvin is partially blind.  For hearing, Simon is a Deaf man and Madi [phonetic] is partially Deaf.  [Indiscernible] is dyslexic.  Thomas suffers from musculoskeletal disorder known as Down's syndrome.  Suzette is an older woman.  Eric is temporarily disabled.  He has to lay in his bed for two months.  He can only use his smartphone.  And Dong is Chinese and doesn't speak French.  He's also color blind.  Next slide.  

To make our different objectives, we have created an online pool presenting four types of content.  A technical sheet, the personal sheet, a summary sheet, and a poster.  Let's look at them one by one.  The poster.  Here is Angelique's poster.  We see the photo of her.  Her first name and age, her job and disability.  A code that characterizes her, and a QR code that allows you to have access to the full descriptions online.  We create posters to put them on the wall of the corridors on the elevators of the company to arouse curiosity.  We also want to put them on the wall of the meeting to our project teams to always keep their target in mind.  

Next slide.  Thanks.  The summary sheet summarizes a full page.  The information is present on technical and personal sheets.  It needs to be printed to be used during creativity and design workshop.  Finally -- no, next slide.  

Finally, there are two, the first called personal sheet described the persona's biography, passions, happens and daily frustrations.  This sheet is intended to marketers and UX designers.  For example, Angelique has been blind since birth.  She has a degree in English.  She's also a talented pianist.  She's an active woman very interested in her appearance.  She loves shopping and how to apply her makeup.  Her frustration is she can't listen to music when going from place to place because she needs to pay close attention to the noise around her for her safety.  

The sheet provides additional information which can be displayed by clicking on links for information features.  If you click on the word, you can discover for people that are visually impaired.  If you click on the word "colors" there's an information book which explains how to describe a color to a person who has never seen one.  It's possible to share it with sensations.  For example, red generally associates with sunburn, or when you are facing an embarrassing situation, your cheeks turn red.  

 

 

The second sheet -- next slide -- is titled, technical sheet.  It describes the persona's use of technology.  What tools in assistive technology he has and above all, what digital program he may deal with.  For example, at work, Angelique spends her time at the computer listening with one ear to her screen reader and the other to the personal.  She use as reader and keyboard.  It can be very tiring.  

She would like not to use personal technology in her personal life but it's impossible not to use the internet.  Example of technology based limitations.  Angelique as her reader configurated to links within her page.  This sheet is intended for accessibility experts, project owners and developers.  

As you can see the word links and underlined, as we show you, each persona is directly linked to a deadline base, user stories, testing and corresponding tools.  Go ahead, Vincent.  

>> VINCENT ANIORT:  Thank you, Nathalie.  What we're working on is creation of all the links to combine each of our documentation and tools on our open source internet site.  These docs and tools are on the personal site, of course.  Our explanation of a WCAG 2.1 criteria.  Our accessibility methods.  Our user story set to using methodologies and the method and tools used to test.  All these are linked together to other projects to have explanation on the how's and why's and to better understand all the implication involved between all these documents.  

Next slide.  Navigation between persona and user stories.  Navigation -- excuse me.  When you are project owner, you can be interesting to access the personal related to the impacted public or for user story to know which type of real user is impacted by which kind of acceptance criteria.  It's even more important when we talk about accessibility, of course.  

So these are the links but it can be important to know a certain impaired user, what their technical limitations are.  Each of the stories on the same template with item description in front of as an impaired user I want to do something, and acceptance criteria.  And given I have this kind of impairment when I use this functionality, then I can get that result.  If needed, some specific management tools.  The person impacted and the WCAG reference.  

Next slide.  Navigation between persona and guidelines.  Our guide lines can, for example, help a person better understand the type of impaired user who are impacted by a guideline and conversely, when someone reads a guideline for user impacted, it's also on the same template a title, target, the type of impaired user, list of person impacted, project phases, and guidelines should be taken into account, description for list of things to check, user goal, a do and don't, and the WCAG reference.  

Navigation between persona and testing.  Procedures to follow to test a specific guideline linked to guideline, but also linked to persona when type of person is impacted by a specific test.  For example, a blind user test on the -- with the keyboard.  These test are also built on the same template with title and how to that explains step by step how to identify the element to check.  A list of checks for each item element.  Results expected.  Designer, developers, accessibility experts, list of persona and tool used if there are any.  

Next slide.  Navigation between persona and methods and tools.  Sometimes you need an explanation how to use a guideline because you have to use specific assistive technology technique or two and you need to know how to.  For example, the way to use and test the screen reader.  We are linking persona to methods of test.  

Next slide.  Persona links and sheets.  We should be proud of our accessibility guidelines site.  Persona put a user in the center of a design process.  Persona set will gather all the links to our documentation, tools.  When needed, there are links between our story set, our guide lines, and tools and methods.  Tools and methods in the story are already linked to each other.  We are currently working on the user interface and how to simplify it to be sure it will be user able.  And really helps project to take into account accessibility, be more empathetic with users.  We are still working on, and we hope to be finished by the end of this summer.  Next slide.  

In conclusion, this persona, first feedback from project owners.  Project designer, managers are pretty good.  It's useful, practical, educational and agile.  The persona is the center of the interview to build current accessibility documentation and way to utilize accessibility.  That could be the right thing to do.  To be sure to take into account the user, and therefore, accessibility during their digital projects.  Thank you, and let's go to the questions.   

>> MODERATOR: Thank you so much, Nathalie and Vincent.  Let's get into the questions.  Gabby asked, I've seen personas be used as an excuse not to have to talk to users, how do these personas intersect with usability testing in your practice?  

>> VINCENT ANIORT:  We're not really using persona to -- usability testing.  When we need to -- following a project in accessibility, we have specific employees with impairments.  And we are -- we use them to make some usability testing on the applications to be sure there will be no barriers for what kind of people, impaired people.  And much of the time, it's people using screen readers because a screen reader is best way to find accessibility bias.  So we're not using persona to make our usability testing.  

>> MODERATOR: So you're not using personas to replace usability testing.  

>> VINCENT ANIORT:  Yeah.  

>> MODERATOR: Great, thank you.  So there's a ton of interest in your personas themselves.  One person is asking if they're available for other people to use or perhaps look at or borrow from?  

>> VINCENT ANIORT:  I didn't hear the question.  

>> MODERATOR: I can repeat that.  A lot of people are really impressed with the personas you've created.  And they're wondering if they, themselves, can look at them or use them or perhaps...  

>> VINCENT ANIORT:  Yeah, of course.  Like our guidelines and user stories and so on, as you can see on the screen, we have a site with all the personas will be put I think next month.  The summer, okay.  

>> NATHALIE PICAN:  On the summer.  

>> VINCENT ANIORT:  This summer, it will be available, the persona, the ten persona, in this location on our website.  And, of course, in English and in French, too.  

>> MODERATOR: Fabulous.  So for anybody who is on the stream right now, you can follow the website posted here and in a couple of months the personas will be posted, is that right?  

>> VINCENT ANIORT:  Yeah, summer.  Next summer it will be up.  

>> MODERATOR: Awesome.  Next question is, how do you make sure in your process of developing personas that you're being as inclusive as possible for people with disabilities?  

>> VINCENT ANIORT:  We have made the -- a lot of study on the different persona set already existing.  We are -- we also ask a lot of people with impairments before doing our own persona set.  So we think we have something that represents all the kind of impairments in this persona set.  But if there's something missing, we can, of course, add more persona to our persona set.  So it's open, too so you can contribute and we would be delighted to have commentaries.  

>> MODERATOR: So people can contribute with, perhaps, their own personas and help them grow and develop over time.  

>> VINCENT ANIORT:  Yeah, it helps.  

>> MODERATOR: Awesome.  And as a segment off of that question, can you describe a little bit further the data or the research that went into creating the personas?  

>> VINCENT ANIORT:  Nathalie.  

>> NATHALIE PICAN:  We study different articles and we interview different people.  And we have -- [speaking French].  

>> VINCENT ANIORT:  Over persona of impaired user, but we focus on digital and technical impairments and not all the impairments existing.  

>> MODERATOR: Thank you.  

>> VINCENT ANIORT:  It's why there's only ten personas.  

>> MODERATOR: Right.  Okay.  So the next question here is from someone who is looking to make inclusive personas at their company, but are looking for ways to help their co-workers and colleagues embrace accessibility when they're very data driven.  So can you explain how somebody might want to create personas at their own organization, but their organization might not be as focussed on accessibility right now?  

>> VINCENT ANIORT:  I think that one -- a good way to win people on accessibility and persona, it's to put posters on the corridors, entrance rooms and meeting rooms, link it with a QR code to a page on the site to explain more about the persona.  I think it's really -- because when you see the poster and you don't know exactly what it is, it's really -- you go to the site where you can explain in detail the persona and why it's important to take into account accessibility for that kind of person with this kind of impairment.  

So I think it's -- at least arrange posters of the job to people on accessibility.  And technical problems for impaired users.  

>> MODERATOR: So really making the people around you of what accessibility is and what a disability is.  

>> VINCENT ANIORT:  And why it's so important to make things accessible to these kinds of people, yeah, exactly.  

>> MODERATOR: Gotcha.  Great.  All right.  Let's see.  Do you include people without disabilities in your persona set or just people with disabilities?  

>> VINCENT ANIORT:  It's only people with disabilities because it's a persona set of people with disabilities.  There's many persona set of people without disabilities.  So if we need people without disabilities, we have many associates, but for people with disabilities, there's not much persona set already ready to use.  

>> NATHALIE PICAN:  Temporary disabled.  Because everyone, we can all have a disability, temporary.  

>> MODERATOR: That's true and a good thing to include, right.  

>> VINCENT ANIORT:  Yeah.  Not a real impaired user, just temporarily impaired.  Yep.  

>> NATHALIE PICAN:  We have also Dong is Chinese and it's not a disability, but when you don't speak French, we can -- 

>> VINCENT ANIORT:  It's difficult to learn.  Of course it's difficult to understand.  Or you want to speak in English, sometimes it's a bit difficult.  

>> MODERATOR: Right like a lot of accessibility features, like captions, for instance, are helpful to non-native speakers of that language but also great for disability features.  Excellent.  Another question is asking, how do you respond to advocates with disabilities who express concerns of the creations of personas because they can't completely replicate the lived experience and unique adaptations made in real life?  

>> VINCENT ANIORT:  Yeah, good question.  It's a tool, it's not -- it can't be real people and it can't be a real situations.  We cannot really -- it's not the aim of persona set to be a real person, so I have -- we cannot respond to that kind of question.  It's not real.  It's a tool.  

>> MODERATOR: You can get as close as you can.  

>> VINCENT ANIORT:  Right, but it will never be real.  Just a tool.  Another tool.  

>> MODERATOR: Good point.  

>> VINCENT ANIORT:  Close to reality, but not real.  

 

>> MODERATOR: Here's another question about language barriers.  This person asks, I'm curious how language barriers between people creating personas impacts persona development?  This person is wondering, does it help foster empathy or does it create an additional barrier to I guess accurately describing a person?  

>> VINCENT ANIORT:  A persona set is in multiple language.  It can help people with another language to be much more with accessibility but if there's a real language person barrier between the persona set and the real user of a persona set, yeah, it's another barrier.  The only way to be sure is to translate your persona set into as many languages as you can.  For example, in Orange we have a Polish team, we have Spanish team, so we know one day we'll have to translate into Spanish and Polish for sure, but it's hard work.  

 

 

>> MODERATOR: Sure.  Well a good accessible user experience should speak for itself, so to speak, right?  

>> VINCENT ANIORT:  Yep.  

>> MODERATOR: Awesome.  I think we can sneak in one more question.  Michelle asks, how do you manage working with a large set of personas in your process?  Do you check each persona for every feature each time or do you select the personas specifically? 

  

  

>> VINCENT ANIORT:  We are selecting for much impacted persona for functionality.  And we only use two or three persona, which more impacted and that the other technical barriers, most important technical barriers.  We are not using all the persona for each feature.  It's too long to sit.  

>> MODERATOR: Got it.  I could see it would be much more manageable that way instead of going through each persona for each piece of functionality you build.  

 

>> VINCENT ANIORT:  Yeah.  We try to choose the most impacted users for personas, yeah.  

>> MODERATOR: All right, excellent.  Well, we can keep the rest of our sessions on track, I think we're going to wrap up now.  But thank you so much, Nathalie and Vincent for your presentation.  

 

 

Type: Breakout

Track: Organizational Success with Accessibility

By making your website accessible, your organization can capture a huge, overlooked market share, reduce your legal risk, lower call-center costs, and boost brand value.

 

Building accessibility into your development process and reaching your compliance goals shouldn’t be disruptive to your organization’s development velocity, or business operations. In fact, having an accessible website that is inclusive, increases brand loyalty, and expands your organization’s reach to a “hidden” market of $490 billion.

 

Greg Williams, Accessibility Program Office Executive at Deque, discusses the ROI of building accessible websites. You will learn:

 

How shifting accessibility left in the development process is more cost-effective than fixing accessibility defects in post-production.

How accessibility can help meet omnichannel goals and reduce costs.

The revenue potential by adopting accessibility captures an overlooked market share and boosting brand value.

 

>> Hello, everyone.  This is 

Leeann from Deque.  Thank you

for returning to the Return on

Investment of Accessibility. 

Please hang tight as we get

folks settled.

>> Hi, everyone, I'll be

moderating today's session on

Return of Investment of

Accessibility brought to you by

Greg Williams.  I'm going to

take a few -- care of a few

housekeeping items.  Today will

be hosted on demand for

registrants.  Second, slides for

today's session are available on

the website.  If you require

live sections for today's

session, you may access those on

the session page just below this

video stream.  Lastly, we'll

save the last 10 minutes of the

session for Q and A.  So please

post your questions in the Q and

A section, also located next to

this video stream.

Throughout the session you can

chat with the attendees in the

chat next to the video stream. 

You can sort messages by recent

messages, with that I'll hand it

over to Greg.  GROIG thank you

very much --

>> GREG WILLIAMS: Thank you,

welcome everybody to Axe-Con,

and this afternoon's session, I

think getting started now.

A couple Quebec things, you see

the chat you have there, some

people were talking about not

seeing it scroll.  So you might

want to switch it to most 

recent.  So you can see the

comments as they come in rather

than most popular, which is by

default, I think.

The other quick thing, just to

say I know if you haven't gotten

your book yet, some of the

things I'm going to talk about

here, a lot of it actually tunes

directly into the book that's

been discussed earlier today, so

make sure and get your book and

read through that if you haven't

had a chance to do that.

I'll go ahead and get started. 

The Return on Investment of

Accessibility.  I was listening

to the keynote speakers, and as

we talk about this, I think it

was said, ROI doesn't sound like

the right term here.  And he's

correct.  We really shouldn't

think about things in that way. 

But the business world being the

business world, we have to.  So

I may change the title on this

at some point.  More to talk

about the business case of

accessibility, because the

reality is, as you try to add

accessibility into your

organization, especially to do

the work to make it sustainable,

it's going to cost money and

time to do that.  And money and

time, when you're thinking about

being in the boardroom, just

saying it's the right thing to

do, unfortunately is not always

going to get you what you need. 

I think it should, and I think

some day it will.  But for right

now, we have to think about

these other aspects of it.  So

the information I'm going to

share with you today is going to

help you to paint that picture,

to maybe illustrate for people

who don't quite get it yet that

not only is it the right thing

to do, it's also just good

business as well.  And good

business for four main reasons

that I'm going to share with you

today.

So what are the aspects of

return on investment for

accessibility, or what are the

business cases that we can talk

about?  And as I said, there's

four main ones I want to 

discuss.  Those four will do

some seriously positive things

for your organization.

The first thing to think about

is your market share.  And we're

going to talk about market 

share, we're going to talk about

ecommerce.  We'll talk about the

disruption of COVID in 2020, and

what that meant to ecommerce and

what that meant to people who

might not have had any other

options other than the digital

storefront to be able to get the

product or service they wanted.

So we'll talk about that, we're

also going to talk about

operational costs, and this is

operational costs in the

omnichannel organization.  If

your organization has brick and

mortar storefronts and you've

got a digital presence, call

centers, we'll talk about how

shifting those costs in the

right channel are going to help

you and you can do that with

accessibility.

We are going to talk about risk

profile.  This is the lawsuits. 

And although I think this is

really a negative motivational

factor, and I put it third on

this list, in fact I should

probably put it fourth on this

list, but I put it third on

purpose because I don't think

that should be the main thing

that we pursue here, because the

value of the first two that I

talked about there, outweigh the

value of risk mitigation.  And

probably the fourth one, which

saw lining your digital presence

with your company core values

and thinking about things like

social justice, again, more

valuable to your company in the

long run, if you can get people

to think in those terms.  I've

helped dozens of companies

 

create a case, and get the 

funding they needed to produce

accessibility digital content,

so I'd love to help you as well.

     Let's talk about market

share, and e-commerce.  I've got

claim your portion of the pie. 

It's a big pie.  There's a lot

of money and a lot of people

involved.  And I'm going to talk

about the U.S. market place.  I

do have efforts to get data on

the European market.  Different

places where I'm trying to get

more information, it's a little

harder to come by there, but

there's a similar story.  And we

know there's similar situations

exist, but let's focus on the

United States.

     We know the after-tax

disposable income for 

working-age people with

disabilities is approximately 

$490 billion, just short of 

$500 billion.  And this is a

group that are likely going to

need some type of accommodation

to work with your digital

storefront.  If you have a

digital storefront that's not

accessible or you're trying to

provide services and there's not

an accessible way to procure

those services this, is the type

of share you're looking at not

servicing.

     What does 4 husband 

90 billion mean in the larger

scheme of things?  The

African-American market is 

501 billion, and the Hispanic

market is 582 billion.  A

significant amount of money out

there and people who are looking

to achieve goods and services, I have a friend of mine, he said it's a great time to be blind.  And what he meant by that is that there's more than one choice for people today when before there were fewer choices.  If you're not accessible and your competitor is, somebody is just going to switch over and get their product or their service from somebody else

Then we talk about the people.  So 20 million, 35% of all people with disabilities, U.S. working age, adults age  16-64, this data comes from several sources, but I also heard Mr. Serf, talking about permanent or temporary disability.  Lots of money, lots of people.

We look across that disposable income, and say, where do we see which disabilities in this income statistics and this data we  have?  On the chart that I have here, it shows the disposable income again in billions.  So you get that billions scale.  But vision difficulty hearing, self-care, ambulatory,  cognitive, and independent living, with independent living being the highest and ambulatory being the second highest, and hearing and vision difficulty next.

This gives you an idea how those numbers are spread across the disability community.

Then picking that a step further, let's look specifically within the e-commerce specific data.  So from the e-commerce statistics that we can get, we understand, these are numbers from 2018.  I've got some draft numbers from 2019 and for a lot of reasons we probably will think of 2020 as an anomaly.  But in 2018, the approximate total there was $517 billion.  So based on some research that Deque did, with the research company, we commissioned a company to help us with this, 2% of those total e-commerce transactions are completed by people who are blind.  This is assuming less than half, so that 5% of the population, that means that total market available there is about 10.3 billion dollars.  Just that one piece.  So that's the e-commerce market size for accessibility.

And if we look in that research, we see that 90% and Dylan mentioned this earlier today, 90% of internet sites or maybe higher, have critical access bottle bill blockers -- accessibility blockers.  There's something in the flow, whether you're trying to get a service, buy a product, or pay a bill, that's keeping people from achieving the intent of the content.

So that's a I have high number.  And so if I take that 90% and I'm going to use the numbers here, that inaccessible e-commerce, retailers are losing out on 6.9 billion dollars a year, and to just give you an idea of the scale, I like to give people the scale of the numbers we're talking about too, Home Depot.com reported an annual revenue of 6.94 billion in 2019.  An entire Home Depot's worth of revenue is being lost out because customers don't just abandon that purchase, they're going to buy some place else.  They have other options.  They're going to use those other options

If you are talking to the people in your company who are making the financial decisions, if you're talking to them about the need to service this community, absolutely talk about that it's the right thing to do, but it's the fiscally responsible thing to do.  You look at these numbers, how can you say that a company with shareholders wouldn't say, this is something we should focus on?  Absolutely should.

The next thing I want to talk about is I want to talk about operational costs.  So let me define that a little bit for you.  We talked about omnichannel organizations.  Organizations that would have perhaps a mail-in center.  Let's use financial as an example.  They probably got some type of mail-in center where you can make payments or deposit checks.  They've also probably got brick and mortar, so if your brick and mortar branches, they're going to have the website, where you can do most if not all of your financial transactions now.  And there are -- they're going to have some type of call center where you can call in and get service and probably execute those same transactions.  In fact, a key for most omnichannel organizations is that this be similar if not exactly the same across each channel, and also give you the opportunity to pick up and move from channel to channel during whatever task you're trying to do.  So you may start out on the web, and end up on the phone, vice versa, however it is you're trying to complete your transaction.

So in doing this, if your digital channel is not accessible, obviously you've got a large hole in the  organization.  And one of the biggest holes in terms -- it will be just in terms of cost, because typically, and I would like to say always here, but I'll say typically but I can't imagine the digital channel is going to be the cheapest way to do business

I've done a study here, and this is when an actual fortune  500 company.  We were looking at the mechanics and the cost around making a payment.  Simply making a payment, a credit card, a car loan, a home loan.

If you looked at the cost of making that payment in this organization, if somebody walked in, this is a brick and mortar staffed agent facility, we're going to account for everything that goes on here all the way down to the power and the water for the facility.  Everything it takes.  About $15 to make that payment.  From a call-in perspective, you still have the brick and mortar facility, you've got a staffed call  center, trained people there, so although there aren't the call centers are typically large and fewer of them, it's still going to cost you some money.  But they do cut that money down to  $7.50, in half.

From a mail-in perspective, another brick and mortar facility, and I don't know if you have ever seen these giant mail sorters that take the envelope and open it up and pull the check out and scan the check and deposit the check, but it's quite the operation to see.  But there's also a ton of mechanical interaction.  So also some very costly places just to set up, let alone run with the people and the technicians you need to do that.  But it's a little cheaper at $2.50.

Finally, click-in.  I've got somebody coming into my virtual digital website, and doing this make a payment transaction, and again, I'm  taking in all the costs.

The data center costs, the servers, the power, the cooling, but it's just 50 cents for somebody to make a payment.  The difference between walking in and clicking in, $14.50.  Making a payment on your card.

So let's see, if we want to have a proper channel mix for our company, very likely we want to minimize walk-in and we want to maximize click-in.  So here we have what we want versus what it actually is.  What most companies want is they would target maybe 5% or walk-in.  Wherein actually it's probably 60%, but it's declining.  Your people go into banks every day, but still do the same transactions to get the same services.

Call-in, maybe 15% is the target is actually 20, mail-in, 20% of the target, it's actually 15.  And click-in, the target being 60%, but the actual is 5%, we're still in a position where the majority of the transactions  that we see people doing are not necessarily the e-commerce transactions, but that grows more every year.  And again for 2020 because of COVID, we saw a huge spike in the amount of activity in these digital storefronts.

Now, the channel costs for 1.5 million payments, if you look across though, I'm going to take the actuals.  60% walk-in, 20% call-in, 15% mail-in, 5% click-in.  I used the costs that I had before, is going to come out the total cost of payment processing all channels per month, if I think about  1.5 million transactions, which some of you, your companies are large enough you probably have  1.5 million transactions per  day, or 1.5 million transactions per hour.  We'll just say  1.5 million, we want to keep the numbers safe and easy to work with.  16.35 million dollars.  To take those 1.5 million make a payment transactions in a month.

What I'm going to try to do is improve the accessibility of the digital channel because I want to increase it.  So I had looked at 5% actual on the digital channel, which is  click-in, and I'm going to increase that up to 15%.  And for that total that I took for the 10% that I'm adding to the click-in, I'm going back and forth so you can see the difference, I'm going to have  15% now and add that reduction of 3.33% across those other channel and say walk-in,  call-in, mail-in will decrease by 3.33%, but click-in is going to increase by 10%.  I'm using the same per unit cost, I'm  using the same 1.5 million payments per month.

So if I improve the accessibility of the digital channel and I can add more people there, which I likely will, if people were using it before, now the total cost of those payment processing using the -- is going to cost me about 15.2 million.  The difference there comes out to a monthly savings, just for this one transaction, and then just a  3.33% change from one channel to another, to that monthly savings of $1.162 million.  If I look at this over an entire year, that  $13.9, almost $14 million, and who couldn't run an outstanding accessibility program on  $14 million a year?  In fact, who couldn't run an outstanding program on half that much?

If you're trying to make these numbers fit something that's going to get your chief financial officer's attention and you're in an omnichannel organization and they're trying to improve the usage of the digital channel, but it's not accessibility, this is a very concrete way to not only show them how you can gain money, and pay for more so you've got return on investment, because how much you've spent on accessibility is eclipse order how much you're going to save the company in these ownership rational costs.  This is some outstanding information to help them see that.

And by the way, after we do that, let's watch it and try to figure out some way through feedback or other mechanisms to attribute the growth in the digital channel to the usability overall to the accessibility of the channel

 For -- again, those organizations that have this, this is an outstanding way for you to show what's going on in those channels and to show your senior folks how this makes a big difference and how it actually pays for itself.  That's the second way to do it.

Let's talk about the aspects of that, though, before we get into the third one, and what I want to do is again, this was the study that Deque had commissioned that we did with people with disabilities group primarily people who are blind, and we interviewed them and collected information, but what we saw is that people who are blind call a company's customer service department once a week on average because of accessibility issues.  90% of those that we talked to said that they call multiple times to report an issue, even though they've maybe abandoned trying to do the transaction.  So  again, remember those costs, the cost difference between somebody calling in and somebody calling in multiple times for an issue and just imagine the cost of that continuing over time when you could address that cost by making your digital channel fully accessible.

Now let's talk about risk management.  This is the one that I think everybody starts out with.  It's the lawsuit.  Everybody is scared of the complaint, everybody is scared of the lawsuit.  We heard earlier this morning Christina talked about, she gave an entire hour's worth of updates on statistics, which I've got the same statistics in here, just for illustration.  But when we look at the situation, there are a lot of lawsuits that people are filing, and they're filing them in federal court, they're filing them in state court, they're ADA lawsuits, the Department of Justice gets involved.  The reason that's occurring is because we have the Americans with Disabilities Act.  We have Title II, title I, which covers what you must do for your employees, Title III.  Places of public accommodation is likely where you would see a complaint or lawsuit if your digital storefront is not accessible.

 

 

So let's talk about that and talk about those costs for a little bit.  One of the things you'll see here is the study that I did here, again with three fortune 500 companies, was to look and see what the actual cost of that was.  I have an entire presentations  that just on this part of it.  So you can jump out and look at that on Deque.com.

I'm going to summarize it here.  Why do we need to talk about it?  We obviously talk about it because I've Typhoon Koppued about that growth.  These are the year over year title three lawsuits filed, all basis, so this is both fiscal and digital accommodation.  But you can see in 2013, we had  2,722.  And year over year, some years with huge increases like from 13 to 14 with 63% increase, but then sometimes smaller, so 19 and 20, we'll consider 2020 an anomaly year.  Staying about the same or decreasing a little bit.  But we've seen those go from 2,000 up to -- in excess of 10,000 a year in 2018, 2019, and 2020.

 

In fact, what Christina shared with us this morning, I think they expect 2021 based on early data may be a record year because there's probably some pent-up frustration last year, things that were illustrated we maybe wouldn't have seen without the COVID lockdowns as well as action that didn't get taken because everything was locked down.  So we could see quite the year this year.

And thin where we are -- are we seeing these things focused at, I don't have the graphic for California on here, I couldn't get it in time, that's how late-breaking some of this is.  Where do we see those, this information from this morning's presentation, so California has about 5800, New York has 2200, and Florida having 1208.

They be they continue to be spread across a myriad of different industries, both products and service.  So there's really no place that's absolutely safe from these types of lawsuits.  If you are selling a product or service.  And you have a digital presence and you have a method for doing and providing services in a digital channel, then you need to make that accessible.  If you don't, very likely you're going to eventually see a lawsuit in that space.

So let's talk now about the cost of the complaint.  I want to talk about complaints first, then I'm going to talk about lawsuits.  What I'm doing here is I'm collecting information on what actually occurs when a complaint happens.  Not just the actual fine and settlement costs and lawyer fees and things that come from the lawsuit, but what actually happens?  What things occur?  Call center people have to get involved and probably call center management, we've got your compliance and regulatory people involved, your product management, developers, testing, deployment operations, because theoretically whenever the complaint comes in, you're going to have to fix it.

 

 

I've got a big chart that I'm not going to completely cover in this presentation, but of course once you get the presentation you can dig through it in the table.  But what this is showing is the number of people involved, number of hours they might spend working on this complaint, and the extended cost based on an average cost for people in your company.  So you can use the average hour for whatever you like, but you can see that when you get the complaint, you're going to have somebody who receives the complaint, you're going to document it, you're going to process it, you're going to spool up a project to fix it, then you're going to have to design code, and test what you're doing.  Then you've got to issue it back out to production and spool down the project and then finally follow up with the customer.

So you can see the extended costs on these.  It very quickly adds up.  It adds up to a lot, right?  So the reactive fix cost here that we have is about 9,9 hundred freezing rain, when I add everything up in this  extended cost.  What we're talking about in scale factor versus design, that potential cost of this complaint, if you're practicing accessibility and you have a defect injected in the design phase and youd a receipts it, let's take an example, we should have had alternative text on an image that means something to the content, and it wasn't put  there.  If I fix it right then it's a very quick fix.  I've  fixed it in design, there's probably one or two people involved, we're done.  So the proactive fix cost on that is going to be very cheap.  It's going to be probably an hour or less of somebody's time.  Hopefully for an hour or less

The reactive fix loss we just figured up is almost 100 times that much.  So that's how much more money we're injecting into that when we see the reactive fixed loss at  9,949,000.  When you -- if you get a hundred complaints over a year and each ones  that type of activity associated with it,  now, this is probably going to be worse case, because hopefully you would bundle these up and put them in a project instead of having a project for every one.  But we'll take the worse case number and say it could be upwards of a million a year.  This is responding to complaints and fixing issues you've found in production versus fixing those issues when they occurred, or not having the issues at all.  This is what Deque refers to as shift left, shift left means you're fixing the issue, you're addressing accessibility as  early in the software development life cycle as possible.  And that's where you save the immense amount of money here.

 

 

Now I want to talk about lawsuits and what happens with a lawsuit.  Which is going to have some of the same activities that we have with the complaint, but now we're going to add some very expensive people.

In fact, I'm going to take the blended rate up to $225 an hour and say I've got senior company leadership, I've got those compliance regulatory personnel, internal legal counsel, internal legal support, internal subject matter experts, external subject matter experts, centralized accessibility team leadership, developers, QA deployment operations,  marketing.  Realize that all the people that I've listed here, all of these skill sets and all of the resources that I have, this is really what it takes to do.  That's what happens at these companies, these people have to come out and deal with this lawsuit and you're probably going to have to keep your C suite up to date on what's going on too.  It's taking expensive time from expensive people.

So the potential costs  here, you're going to have as I said, more expensive people and more expensive resources, it's going to have a protracted response.  There are very few lawsuits that happen over a short amount of time.  This is going to be burdensome.  Somebody is going to have to keep things rolling and figure out what's going on and report it back, and get direction, and take action.  As I said, it's going to involve the senior levels of your company, because they want to know about their company's aggregate risk.  I would if it were my company.  And typically it's also going to call for outside counsel.  So you're probably going to have to hire a law firm who can practice where the lawsuit was filed.

And who has experience in dealing with accessibility or Americans with Disabilities Act lawsuits.

So we're going to go back to the same type of table here, but you can see that now I'm talking about things that happen when the lawsuit comes in.  So the lawyers are going to have to be assigned, the business is notified, you're going to have to retain outside counsel, so you can see I've put a cost in for that.  You're going to have to issue hold orders to people.  That means during a lawsuit, you can't destroy any records that may be pertinent.  There's special processing that will have to take place so you're not doing any illegal records management, I'll put it that  way, on things that pertain to the case.  And that actually takes people time to do.  To identify those things and set them aside.  Some judges order very early discovery, so if the judge orders early discovery and you have to provide things like your policies and maybe your internal standards, or your software development life cycle documentation, that's going to take time.  You're going to have to prep for court status hearings, you're going to have to prep for negotiations, you're going to go to court, negotiate all these things that you're going to have to do, and keep in mind that this illustration is for a small quickly settled lawsuit.  This isn't even  counting one where you've  decided to contest and it we're going to go to court and fight the issue.

Then you've also got settlement drafts, settlement draft reviews, finalization processing, and now you've got to release your hold orders, so all those records that you kept, now have to be released so they can be destroyed when they're supposed to be destroyed on your regular retention timeline.  And then you've got to close the project and file and document everything.

So this means your litigation grand total, again, just the activities the people are undertaking in these  extended costs, plus your outside counsel retainer, so there's two things not  represented.  I haven't represented any potential DOJ fines issued, or any damages.  And also I haven't listed anything for a settlement cost.  So $356,775 just in activity of people doing things that are required when you receive and have to process a lawsuit inside of your company.  An immense amount of money.  Much higher than -- you hear people I settled it for 20 or $25,000.  Well, 20 or $25,000 plus the  $350,000 you just had to spend on all this activity.  There's no such thing as a cheap lawsuit in this space.  And I've had, I presented this a couple years ago, and there were a few lawyers, and most came and said they thought my costs were actually low here.  So we might use this as the best case example instead of the worse case example.

Then think about something else you could add on top of this, which could be potential DOJ action.  We heard this morning the DOJ could levy a fine up to $96,000 and change for first action, and $192,000 for subsequent actions.  As well as requiring your website to become accessible in probably a very aggressive amount of time.  So they're going to force you into action that's going to disrupt your company, it's going to take extra time and money and just not a good practice to get into when you could have spent all of this money proactively on building an accessible website.  Between, things that may or may not happen to your company, but things that have happened to a ton of companies and money that they've put some place other than where it would have done the best good for the company for the shareholders for the customers.

We've talked about the numbers, we've talked about the market share, e-commerce, we've talked about the channel costs, we've talked about risk.  Now let's talk about alignment with core values and let's talk about social justice, or to I think quote Mr. DSerf this morning, it's just the right thing to do.

It is the right thing to  do.  So what I've done here is just collected some company mottos, if you will, and I'll just read through them real quick.  You can maybe you'll recognize the company and maybe not.  But there's a cheat, at the bottom of the slide when you get the actual deck there's the names there.

Here to help life go right.  You're in good hands with.  Or life's better when we're  connected.  Our clients' interests always come first.  Leading a way.  Where there's a helpful smile in every aisle.  Our vision is to be the earth's most customer centric company.  Or, be what's next.

So with mottos like that, if your mission stated, again, look back and read them again, if your mission is to be inclusive, connected, customer driven, how can accessibility not be part of that?  It's just impossible.  So everything else, you going to the marketing people and say, look, you've got a great marketing strategy, but you're not following through with it.  How are you following through if accessibility is not part of what we're doing?

So another strong argument for just doing what is right, and social justice concerns are definitely on the rise, and if you have a group of people that's being treated poorly, let's say, you get a lot of negative press, or perhaps you'll get people saying I'm not going to buy your product, so some Sirius consequences.  So you want to be out in front of it and not behind it.

There's another piece, back in 2019, I found this, and I put it here because I just thought it was very interesting.  And I'll say since 2019, I'm not sure I've seen -- there's a group of CEOs who said maximizing shareholder profits no longer can be the primary goal of corporations.

This was just before COVID, the end of 2019, the story in the "Wall Street Journal" I think is referenced in the slide deck as well, so you'll get  that.  Think about what these groups of CEOs are saying after everything we've seen in the previous couple decades.  Profits is not the only thing that we need to do.  We need to be good corporate citizens.  We need to focus on good for all on inclusiveness.

Another way that you can work this into your  organization.

Again, we talked about social justice issues on the rise, there are tests -- tech companies that face pushback for contracts with immigration and border control.  Retailers face calls to halt firearm sales, increasingly vocal calls on social issues, racism, LGBTQ+ equality, people with disabilities, ageism, pick your issue and I'm happy to say that there are outspoken advocates now for all of these, and I  really like the way this is growing.  But again, because it's growing, you have to think about what you say and being inclusive means you're inclusive of everyone.

So a couple of other things to leave you with real quickly before we get to questions.  Customers are increasingly  looking to spend money with companies that share their  views.  This came from the study that we did.  In that study  also, we found that in the study group, customers who were happy or unhappy with a company because of accessibility, tended to communicate that strongly to their family, and friends, and colleagues, so you got a groundswell of either satisfaction or dissatisfaction based on that as well.

All right.  This brings us down to questions.  I think  Leeann has been watching as we go and home we've got good question and I'll try to answer what you put forth

>> Sure.  Thank you, Greg, that was awesome.  We have a few questions here from the participants.  So one of the questions is, are there any case studies or companies who had seen an increase in profit after making their website or application accessible?  This will be great information and ammunition when discussing accessibility of decision  makers.

>> GREG WILLIAMS: Yes.  The holy grail question.  I've given this presentation or parts of it several times and I always get that question.  I'll say that I think I'm closer than ever before to finding this.   However, it's going to be difficult to find, because companies aren't classified, rightly so, companies aren't classifying the difference between people with disabilities and the other people that are doing business with their companies.  So it's been very hard to pull that out of the data and say that this particular increase in profit occurred because of what we've done with accessibility.  So I'll say I don't have a concrete example of that yet, I'm working with several companies to try to build ways to do that.  But it's tricky to do that because of the way that we certainly don't want to track a particular population through the companies, I that I would be a negative thing to even ask anyone if they're using an assistive technology, it's just not the question you ask.

That's what holds us up from getting that.  I think we'll get it someday, but it's not quite there yet.  Good question, by the way.

>> Here's another question.  If you were to prioritize the various return on investment practices, which one do you think is the most important one to focus on?

>> GREG WILLIAMS: So I think the most important one that's going to help you sell this is probably going to be the market share, and if you're an omnichannel organization, the argument about channel costs.  At some point in your organizational change  management, as you begin to help gain awareness on the peoples with disabilities community, to help gain awareness on how easy it can be to put accessibility into your products if you focus on it at the right time, using the right types of tools and the right types of processes and procedures and guidelines, that people are going to say, oh, this is just the right thing to do.  But until they get that part of it or they truly understand disability accommodation and accessibility, you're going to have to talk their language, and their language is going to be exphoin they're going to want to know how much is this going to cost me, how is this going to save me something on the other end, how is it going to grow my business or meet some type of goal that my business has.  So that's why I think those two are probably key to focus on at this point.  Coming up very quickly is the social justice one, anybody who hasn't had their head in the sand in the last two or three years should understand that that's coming to bear, and start to work on that too.

There's a lot of unmeasurable potential there that I think people are starting to understand.  Also a good question.

>> Great.  Another question comes in, the big picture is to make everything and everyone have the ability to play in the same arena.  With that, the biggest investment is driving consumers to your website, instead of a competitor.  Will you stay that is your best return on investment?

>> GREG WILLIAMS: Ask you that question again?  I'm not sure I got it.

>> I think the question  is --

>> GREG WILLIAMS: Restate the question, I'm sorry.

>> The biggest investment is driving consumers to your website instead of going to a competitor's website.  Would you say this is your best return on investment argument?

>> GREG WILLIAMS: Yeah.  It's -- I think I understand what they're asking.  It is a huge part of that argument to get people to your website.  And I think that we're -- where we typically have not looked at accessibility as a competitive advantage, I don't think everybody always thinks of it that way.  It's becoming a competitive advantage, and it's becoming that way just because of what my friend said a couple years ago, it's a great time to be blind, because I have  options, because I can do different things.

So, yeah, I think getting people to your store and doing business with you and helping them be satisfied in everything before the sale, during the  sale, after the sale, is a key to business retention, and there's just so much competition out there that getting the word out that your storefront is completely accessible is going to become a competitive advantage.  If it isn't already.

>> Here's another question.  Tell me more about why that lawsuit cost in your study seems higher than what I've seen?

>> GREG WILLIAMS: So the difference in what I did and what others have done, people have typically just focused on, what were the legal fees, what was the settlement cost, and what were the fines?  If any?  So if we just focused on legal fees and settlement cost and fines, sometimes those are -- most times those are quite a bit lower.  But it's really all the activity that's generated because of the lawsuit or because of the complaint and not only the activity, but the disruption to your business as you have to address something that maybe wasn't immediately in your timeline.  Now you're disrupting other plans, other movement, and you're trying to do something out of sequence, plus you've got all of this activity taking place with people who have other jobs to  do.  There's nobody just sitting around at your company saying, okay, waiting on a lawsuit, when it gets in, I'm going to take care of those records.  These people all have other jobs.  That's where you're going to get the issues that come in, and that's why I did this study in that specific way, to show you that even if you settle for $1, let's do the price and right, it's now $350,000 and $1, because you still have all that activity.  That's why I think that surprises people, and they like to debate it.  I'd love to debate it to see what your company processes are, I think it's fun to talk about those things.  That's just me.  I would love to have more information on that, but that's why it seems higher.

>> So here is another question, is 2.0 the goal, what is the returns on investment to go beyond that?

>> GREG WILLIAMS: This is a great one.  That's -- this is -- I'll get a huge argument started up here.  I will never advise a company that their goal is to be conform ant with a guideline.  Web content, accessibility guidelines.  It could be the goal, if that's specified in the legislation.  But really your goal is that your content can be used by everyone regardless of ability.  Or regardless of whether they're using accommodation tools or not.  And what that means is that you have some Leeway within the guidance itself to make things  accessible, but maybe not 100% conformant.  Don't get too caught up into the notion of trying to make it 100%  conformant because the last bit you go after may have almost no impact on the user experience at all.  But it's expensive to get to.

Conversely, there are things you can do that WCAG may not require that would have a tremendous impact on your experience, and the way the thing is designed, and the inherent usability.  I sometimes for some things don't go all the way there, some things you blast past it.  Remember, it's a competitive advantage world.  This is becoming -- so the  usability of your website including accessibility becomes something that can set you  apart.  I'll say there's no top end to it, just make sure that you know your audience, and that you're making sure that your content can be used by everyone regardless of ability.  That's a great question.

>> So we have a question from Garrett, he's asking, do you have stories for the return on investment on making internal employee facing systems accessible?

>> GREG WILLIAMS: Yes.  So we didn't really talk Title I too much here.  Unfortunately I've seen, I think this is the lawsuit effect, this is why I don't list lawsuits first.  Unfortunately I've seen Title I, which is you do for employees, get pushed to the back because typically you can accommodate your employees a little easier than you can accommodate somebody out in the public.  But I do have stories about that.  And I'd love to have more and I'd love to talk about them.  You think about an employee, you've just hired the smartest person and the best person for your job, and yet you're not providing them something they need to do their job.  This is the whole neetion, the person wants a PIN, don't save a dollar for lack of a million dollars.  So when you enable that person fully to bring their self to work and to not have somebody beside them reading a screen to them, to be able to schedule PTO on their own, to look at their own W-2, the job satisfaction, the productivity, the increase in the -- in their ability to overcome issues or innovate for your company, it's incredible things you get there.  And so my answer to that is, why in the world would you hamstring somebody coming in?  You want the best people to work.  That's also a very good question, and I didn't have that stuff in here because this is primarily covering Title III.  I'm  gathering information to talk about Title I, so more to come on that one.  Did that answer that?  I got a little excited about that one.

>> We have a question, but it's a little bit on the legal side.  So we might not be able to answer this.  But the question is related to, for legal reasons, do courts go by  WCAG or usability?

>> GREG WILLIAMS: This is a little legal -- I'm not a  lawyer.  This is not legal advice.  I'm just telling you what Greg -- GW, they call me  GW, what GW has seen.  Most is going off of that.  The predatory lawsuits, there's some people out there filing lawsuits just because they want to get a settlement.  A quick settlement.  They use it because it's easy to say I call it the murder  lawsuit.  They list 10 different ways you could commit murder and say, I accuse you of committing murder.  Here's the web content accessibility guidelines, I accuse you of not following those guidelines.  Because that's been referenced at some point through some litigation.

So that's typically what you see people coming through.  It's not about the usability, they're trying to say you're not meeting some portion of that accessibility guideline, which comes back to usability.  But some companies aren't very -- some plaintiffs aren't very specific when they say that.  They'll just quote the criteria and accuse you of not following it.  I think the main thing here is it should be talking about some type of injury, what can or can't they do because of how your website is built or architected?  I don't see it nearly as much on the actual  usability, they're arguing about the guidelines.

>> So I think we have time for about one or two more questions.  Here's another one.  How could we make a case for accessibility in companies outside of the U.S., where the law isn't so clear and the risk of lawsuit isn't a driver?

>> GREG WILLIAMS: Forget about the law and the risk of lawsuits, I guess.  That's number three moving to number four on my list.  I would again say that even though it may not be -- think about a marketplace where this is not required at all.  And think about those market statistics that I just gave you.  Whether we choose to focus on it or not, there is still this community of people with disabilities in the world that may be a billion people.  So if they're not focusing on it at all, and you focus on it, and you create that competitive advantage where nobody else -- that's brilliant.  So I would say focus on those other pieces, especially if they're not mandating it.  If all your other companies are lazy and not doing it, and you do it, think about the advantage you just built.  It's tremendous.

>> Absolutely.  So one last question.  What would you say to people in a company actively trying to stop accessibility efforts.

>> GREG WILLIAMS: Oh, my, actively trying to stop.  I guess I would have -- I've run into this too.  It's happened.  The main approach I have to that is to try to have adult conversation, but sometimes you can't, you have trouble with the adult conversation, because if somebody is saying that, they haven't been informed, or perhaps they don't have data to back up their position.  But try to have an adult conversation about why.  Why don't you -- steer away from, it's the right thing to do.  That's an obvious one.  This is like arguing politics.  If you're a liberal and you're arguing with a conservative, are you really going to change each others' viewpoint?  Maybe not.  But in this case you can change it with data, especially the data I had about the market share, the data I had about the omnichannel, the channel costing.  And those types of things.  So break -- bring it down into a business question and I would bet you're going to be able to back them into a corner on that business question where they can't say this is a bad idea.  Because if it's a large company, you're not going to spend a billion dollars making -- it doesn't cost  a billion dollars make your content accessible.  It's a very reasonable cost when you look at the overall I.T. budgets.  I would say -- I would back them into a corner with those business questions and try to stay away from the emotional parts of it.  But thous a loaded question.  Depends on the person and why they're saying -- why they're trying to stop it.  Some people are just mean!  I don't know!  Hopefully that's not the case, but try to use the data.  Always use the data, data-backed decisions, and back them into that corner and say, I -- here's all the data, if you admit this is right, how can you say this is not the right thing to do?

>> Great.  Thank you so much, Greg, for a great session and thank you to everyone for attending, enjoy the rest of Axe-Con.

>> GREG WILLIAMS: Thanks, everybody, I appreciate it.  Have a great day.

  

  

  

  

Dave Rupert

watched a little while waiting for the other talk to stop having tech issues

found interesting article - How to be an open source gardener https://steveklabnik.com/writing/how-to-be-an-open-source-gardener

He brought up the good point of effort to win - if something gets fixed that gets used thousands of times a day it's a much bigger impact

he also got into triaging, how grouping things together was key to assigning it out and having it addressed without being overwhelmed.

Approach Accessibility As A Customer Experience Imperative: It Starts With Design