Nicky's Journal

Type: Breakout

Track: Design

Often accessibility is overlooked till the last minute, requiring more effort and time to find, report, and remediate problems. By creating a shared library of accessibility specs, designers can avoid creating inaccessible products from the start and build awareness of accessibility within UX and their broader organization. This talk will cover why you should use an accessibility library, what teams at Indeed are using, and how it’s impacted conversations about accessibility across the company.

 

 

 

CART provider is standing by.

>> If you require captions, they are below the video.  If they are distracting to you for any reason, use scrolling to manage whether they are in your view or not.  The session will be recorded.  And the accessible PDF version of the presentation is on a session page just below the video and the captions content near Stephanie's profile.  I'm going to turn off my camera.  All yours, Stephanie.

>> Me?  Awesome.  Thank you, Travis.  Hi, everyone.  Thank you so much for staying through the past two days.  I promise you'll get through this and then separate.  It's been so awesome to be a part of Axe Con.  I was watching Steven's last talk on gaming.  I loved that.  I'm really excited to talk to you about accessibility libraries and essentially how designers can start talking about accessibility and inclusion earlier in the process and why that's a good thing.  A little bit about myself.  My name is Stephanie Hagadorn.  I'm a certified accessibility activist.  Shout out to Texas.  A lot of people repping Texas.  I have two dogs that you might hear.  A warning if they pipe up.  They are out there.  I love all things like movies, TVs, video games, and so when I'm not watching Star Trek or leading an Animal Crossing, you might have heard of Indeed.  We're at the world's leading job site.  We have a motto.  We help people get jobs.  Got it on my shirt here.  It is really a core tenant of Indeed's ethos and baked into all that we do.  It is one of the reasons that I love my job.  Jobs can literally be life changing.  I get to help people find work that brings them meaning and makes them want to get out of bed in the morning.  You might think I'm over exaggerating, but it really is part of everything that we do at Indeed.  Whether it is across every piece of merchandise and it is always leading the crowd of Indeedians at Pride parades across the globe.  You'll see it on all of our signs at career fairs and hiring events that Indeed holds.  We also have pictured here is the little orange chairs.  In every conference room in Indeed when people went into the office we had physical orange chair.  Now we have work from home friendly desk-sized orange chairs.  That's a visual reminder that the job seeker has a literal seat at the table.  We take thinking about our users super seriously here.  And if you are not familiar with indeed, it is seen a lot of change over at the years.  In the past we were focused on all of the jobs.  The Google for jobs.  We optimized the site through thousands of AB tests, user research, monitoring, metrics, data, analyzing data, and you have the Indeed that you see here today on the right.  Part of had my hand in a little bit of that.  While we always put the job seeker first we haven't always considered all of the different kind of job seekers out there and the unique challenges and barriers they face when trying to use indeed.  With the unfortunately record unemployment right now, it's been more important than ever to focus on the job seeker needs.  That's especially true for people with disabilities who experience joblessness at higher rates than the general population.  For the past year Indeed has made accessibility one of the top priorities.  We had a mandate and this mandate was supported by senior leadership and champion and managed by our amazing diversity inclusion and belonging team and this mandate really allowed our teams across Indeed to be able to dedicate more time and effort to addressing these accessibility issues.  But now that we have kind of the permission or availability for the work the big question was how do we do it?  How does a company like Indeed with massive amounts of content and pages begin to tackle accessibility?  It is a good question, Stephanie.  Well, we started like many companies do.  We started running audits both internally and with awesome vendors like Deque.  We conducted site-wide audits with the flow across the site and common actions that user takes applying for jobs, creating accounts, uploading resumés, and captured all of the violations and potential barriers and issues that users would face using our product.  Those issues that we share back with Teams.  They were across marketing and UX, product engineering, and over the year we remediated over 5,000 issues.  We've added transcripts, captions, and audio descriptions to almost 400 video and updated 500 templates.  Indeed sends a lot of e-mails.  You probably have some in your inbox.  Sorry.  Being the data driven company that we are, we looked at all of the violations across the site and tried to figure out where they were happening and what was causing the violations and a lot of them came down to really simple things.  Not meeting color contrast and really visual interaction-related bugs that could have been addressed or caught earlier in the design phase.  So missing these easy fixes early meant costly remediations and 5,000 issues and time spend down the line documenting and fixing those issues.  In fact, IBM did a report about estimating the price of addressing violations after release can actually be 30 times more expensive than if you just fix them in the design phase.  That's a little money.  And so while these issues can be easily fixed, we realize that we needed to address the accessibility fluency to help avoid making the same mistakes other and over and over.  To put it in UX, how might we help designers better understand the accessibility requirements and start designing more inclusively.  So to tackle the gap in knowledge we drafted our own version of WCAG guidelines.  If you, I think many people here are extremely familiar with WCAG.  And are very familiar with the cryptic, verbose, intentionally vague wording.  And so we set out to really translate those declines into easier to understand checklists for designers and developers.  We then -- so you can see the example on the right here of where we've taken the 1.1.1 nontext content rule and wrote it to help our designers and developers better understand it.  So we created a web site internally and actually put together a big training webinar for the whole company.  I know we gave the training to over 2,000 people at company.  We were able to share the new guidelines, examples, and really frequently asked questions in the training sessions.  That really helped to establish a base-line level of understanding and shared language.  Our designers and developmenters were very receptive and eager to learn more about WCAG and accessibility.  When we asked for feedback on the training and guidelines, we kept hearing a sort of similar sensement.  That was, okay, cool.  I'm really glad I have this information.  How do I do it?  The guidelines and training sessions built more awareness of accessibility, but it didn't really give them a clear way of applying accessibility concepts to the work.  They knew what to do, but not how to do that.  So designer, architect, and all around super smart dude said if you want to teach people a new way of thinking, don't bother trying to teach them.  Give them a tool, the use of which will lead to new ways of thinking.  Or sometimes more commonly I refer to a lot as praxis or learning through doing.  By doing something and using the tool we can actually learn more about a concept or idea.  So by providing designers with tools to engage in accessibility practices, we're helping them apply their knowledge and develop a greater understanding of accessibility.  It is kind of like teaching a small army to fish by giving them really awesome fishing poles.  So at Indeed, we primarily use Figma and libraries and plug ins to streamline the work and maintain consistently across products.  For those in the chat or watching who might be unfamiliar with Figma libraries or components, they are little reusable pieces of design that you can easily drag and drop into a file and reuse and modify over and over.  The example to the right is a small animation gif explaining how designers might use these components.

>> Hey, Stephanie.  Can I jump in and bug you for just a second?  Can you move back and recenter yourself just a little bit the way we were before?  .

>> Am I off screen?

>> I'm so excited.  I'm sorry.

>> That's cool.  Sorry to interrupt.  Go for it.

>> All good.  So meanwhile with the WCAG2.1AAA mandate they are being asked to make sure the design meet the requirements beforehanding them off.  Why not make a Figma library that makes the handoff -- there's my dogs -- that makes my handoff easier.

[dogs barking]

>> And simultaneously helps build an understanding of WCAG.  So we did exactly that.  We created an accessibility red line library with a variety of components and callouts to help designers highlight key parts of the page to developers.  If you are unfamiliar with bread lines they are design files to make sure designs are made according to specification.  They are called red lines.  They refer to the red lines they use to communicate the specks.  But in this case accessibility considerations.  As opposed to WCAG, the library's is organized by different elements or content types.  If you are familiar with WCAG, it is organized by perceivable, operable, understandable, and robust, or pour.  It is more focused on the end users of WCAG.  Which are users with disabilities or barriers when using products.  Instead we reframed the guidelines to be focused on the people using them.  For designers and developmenters.  Things are grouped by headings, images, and video, things like that.  To make it easier to know what distinctions or call outs to make in the file.  For example, if I have an image on my page, you can go and grab my image.  I need to include the alt label here so my developer knows what the image should be.  That doesn't leave the developer to say what should this be?  I don't know.  I'm going to call it screen shot.  It is not helpful for anyone.

All of the components are free filled with the protect CSS or HTML elements.  Designers don't have to remember things like autocomplete values.  I know for one the street field you don't have to remember just grab it.  And landmark for footer is content information.  I need to grab the footer and it ensures they are using the right value and as well as not having to guess where landmarks fall on the page.

[dogs barking]

>> Sorry.  I can mute for a sec.  Or what the intent of the page or pattern should be.  We also included this part gets me really excited.  But these little labels for indicating different types of styling whether it is for states of elements or any keyboard mapping for custom elements.  Using the magic of Figma and auto layout and things like that, you can quickly make the table for what the right keyboard mapping should be for the custom component.  I'm a big Figma nerd.  I love that.  Along with the library we also included a handy walk through of all of the components.  How to use them and linked to the relevant WCAG guidelines.  If you are wondering how you should use the image tag or how you could use the auto complete labels, you could look through the guidance and better understand the components.  We also offered step by step examples of how to go about redlining the design with the accessibility library components.  Here an example of a success screen after you submit the application on Indeed.  Now we can label the heading elements and for complicated components like the rating we can say where things might need labels and where other labels might be part of the design and should really get to the Aria label.  How additional operations.  Then we share the library with designers across Indeed.  It wasn't a requirement to use the tool.  Just out there for designers to use it as another tool in their design tool belt.  It took off really quickly.  It is exciting and flattering.  We soon started seeing more and more designers coming to our ally office hours or coming to the slack channel with questions about how to resolve problems with reading order or considerations for custom UI patterns.  Things that designers aren't really come to us with questions about.  It made us think maybe they weren't thinking about before the library.  So one team working on the carousel pattern realized they needed to think through the focus order to make it more accessible for screen reader users.  This lead them to reference for carousel and create a pattern more consistent with accessible carousel functions across the web.  So many teams started making changes not just to new projects or features but as a way to see their existing product through a new lens.  And another team, our messages team, used it to rethink the heading structure of the entire messages experience and that lead them to create a more semantic and easier to navigate page for keyboard users.  The library was also a refresher.  Seeing the guidelines made it click really well for me.  The idea of being able to practice and have the tools to be accessible and think inclusively helped them develop the guidelines.  It shapes how we approach the design practice altogether.  They are thinking more intentionally about how their work impacts persons with disabilities and tools like the library have enabled them to reevaluate work flows to be more inclusive from the start.  For example the design manager said accessible by design initiative to have new ideas from indeed that are accessible from the start.  I'm sorry.  When someone says that it makes my heart jump and so happy.  Each quarter we'll continue to strive for accessibility and keeping at the speed that the engineering partners value.  It really just driving home the point of how building these tools can shift people's mental model.  It is really interesting.  Right.  While having tools like the red line library is helpful in speeding things along, creating tools, practices, and processes with the accessibility first mindset has a far reaching impact beyond just getting the product to market.  The more we think about accessibility the more we are helping the designers think about it earlier and the more we are making it normal part of the practice.  More important from the benefit, it is the affect that it has on the job seekers and employers on Indeed.  In accessible in Indeed means more jobs for more people.  That's my talk.  Super short.  Excited to answers questions.  I'm also -- Travis if we have time, I can always show a deep dive of the library for people to get a glimpse.

>> I think we have a ton of time.  Thank you so much.  There's a lot of curiosity around the library itself just like we talked about before we went live.  There's a bunch of people asking if you are ever considering making that available in the Figma community or otherwise.  I hinted that you were working that out internally with legal.  If you want to speak to that and maybe dive in a little bit more.  That would be great.  I think we have plenty of time.

>> Yeah.  This talk kind of coincided with an article we wrote on Indeed and released on the median blog.  We're working right now in order to publish.  We have to get legal to approve.  It is an intellectual property question.  It becomes creative commons for everyone.  We're hoping to get and needing to check all of the legal boxes.  When that's available I'm definitely going to be tweeting it out.  If you follow me at Steph underscore Hagadorn on Twitter or follow the Indeed design blog on medium or follow anyone on LinkedIn you'll see it there as well.  I can share some of the things that we have here.

>> There's a lot of consensus of deep dive into the library, if you would like.

>> Cool.  Cool.  Cool.  Cool.  From my friend and other folks.

>> I think it is easy to talk about.  You can see what the tools are.  I just updated to support variants.  I'm excited about that as well.  We -- I do have a couple of intro slides.  If you've ever used any of the other kind of Figma-community files, you can just -- they will be set up like a slide show presentation.  You can press the end key and it will flip between the slides.  What is the library for and how to use it.  Accessibility is everyone's job.  100% agree.  Yeah.  Just how to use the kits if you are not familiar with how to use the components in Figma.  We kind of just go element by element on what is the element and how to use it.  We also include a link to the WCAG guidelines.  That's all of the knowledge that you could have for the guidelines.  Here we have made a simple title callout.  At Indeed we have a special one that includes -- we've sort of default set it to end in hyphen Indeed.com.  When you have a title page, they can remain consistent.  They are build with auto layout.  I'll back out to show.  Maybe I can just drop one of these in real fast.  You can see my asset panel here on the left.  I can just grab my little headings chip.  Beep.  I can say actually in the component properties to the right.  This is an H4.  Really it needs to point down.  Then I can just, you know, boop.  Pop that little boy there.  They are all built to point all of the different directions that you need.  I also added a lot of arrows.  For communicating things like labels where you want something to be problematic associated.  I like to use the dash because it is an implied relationship as opposed to -- thanks, Google.  Someone is adding me.  Sorry that it popped up.  You can use the different arrows here.  I can drop one in.  It needs to be an S bend or just a square or any kind of thing.  If you are used to using wire framing or annotation libraries on Figma, right now this is similar.  Depending on maybe the different color of label that you are using.  There's a different color arrow.  You can choose solid or dashed.  That's really convenient.  For things like labels, a lot of times we might have not a visual label but we rely on the Aria label on whether the form is icon or location maker or things like that.  It might be a complicated -- this is an example in your resumé or Indeed profile when you have to say how long you worked at the company.  We want to make sure the to and from labels and specifically the month and date are all problematically associated.  As you are navigating through tabbing through as a keyboard user, you can still get the context that's kind of displayed visually here.  We would hear month from time period.  Whatever voice that you chose for your screen reader.  Mine is an Australian lady.  She's delightful.  Here's an example of auto complete.  You can grab your label.  You can set is that an auto complete label.  Yup.  It is.  It becomes an auto complete.  Then I can choose is it a city, company, country, current password, new password, job title, user name.  I'm always really bad at trying to remember all of the different auto completes that there are.  But this is a nice kind of helpful list.  It includes the correct attribute name for the developers.  You should indicate all of the information on the left before you could read something like save this job or dislike this job.  That came at the end of the card.  Even though visually it looks like it might appear after something like the title or company name.

>> There are quite a few questions, not maybe specifically about the library.  But there's a few that are pretty popular.  If you want to field some of those.

>> Sure.

>> Would you recommend other organizations look into creating their own version of the web content accessibility guideline documentation as Indeed did to help your developers better understand the success criteria required to make an accessible web site.

>> Yeah.  I didn't share some of the examples, but by creating our own, we were able to demonstrate the different guidelines.  If it was about a lot of times forms.  Forms are super big in the apply product and resumé products.  We could use examples from there.  Which I think really helped the developers see how these guidelines applied to their work when we were literally showing their work with.  And I think it was just an interesting process even for the accessibility team to better understand some of the nuances in WCAG and I know people myself that worked together to create the documentation.  I thought the guideline meant this and that.  I had a lot of interested discussions.  It could be redundant.  In a way to help others process, creates a new understanding on its own.

>> Great.  Let's see.  Here's one that came up a little while ago.  I know this person is up very late at night.  Can you talk about the e-mail templates?

>> We have a lot of e-mails at Indeed.  Different kinds of content.  If you are a user, you might be familiar with job alert e-mails.  You'll get a list of jobs in your e-mails.  You might get e-mails directly from employers.  We have templates for employers to put I saw you on Indeed.  Apply to my job please.  That's just the job seeker side.  We have the employer audience for small and medium businesses as well as larger enterprise clients.  There's lots of marketing e-mails that go out to the business side of the house as well as just e-mails that go around internally.  We have lots of templates.  How that looks is not dissimilar from how you might mock up a web site.  Very similar looking.  Just limited HTML CSS capabilities in e-mail.

>> Great.  I'm going to break my uploading rule for a second.  This one came in and it dove tailed into one of the other responses.  Did y'all share your written accessibility guidelines meaning can we use yours?

>> Not publicly yet.  I know we looked at a lot of the other companies who had done similar things.  Expedia has a public version of accessibility guidelines.  My former company IBM has a lot of documentation on accessibility.  We don't have them public yet.  Mostly just I think we've been so focused on serving our internal audiences.  I think now that we're at a better place accessibility-wise, we want to be more advocates.

>> Not yet.  There are others out there that have shared.

 

 

>> Yeah.  I would recommend just off of the top of my head the Expedia one and I would look at IBM and -- I think even just the U.S..com.  Their branding has a lot of -- design system has -- is all accessibility.

>> There were -- there's been a couple of different questions about sketch and alternatives for Figma and can you talk about that for people who might not have the budget?  Is there -- I believe there's a freish version of Figma, if I'm not mistaken.  Can you talk about different budgets and how they might be able to achieve some of this?

>> Figma has versions, I think, where you can send the file to anyone.  So they can view it.  I think even if they don't have a true account.  They will still get things like the inspect panel which will have CSS for certain attributes or for each part of the design.  That can be helpful.  If you use sketch, sketch has components.  You can do the same thing.  They have -- I haven't used sketch in a few years.  I don't know if they have the same capabilities that Figma has recently come out with, a variants.  I know the plug-in community and sketch product have a lot of design components.  Even in the Adobe landscape you have symbols.  It might be more cumbersome or not flexible.  I think you could also -- this is a great challenge.  I think I might take this on.  I bet you could do something in Google slides or PowerPoint.  Just like you make the templates for your company to use, you could make grouped objects that you could easily demarcate parts of your work in.  I think ideas or pieces of this you can take and apply in ways that work.  Almost like reusable, like a little sticker sheet to just grab even just PNGs.

 

 

>> Great for sketch.  I've seen them annotate the designs.

>> Even acrobat or PDF and you don't have the luxury of all of the components built.  Designers are taking more ownership in screen reader navigation and I think we need to start thinking about that part as accessibility as usability.  We should be more thoughtful and intentional there.

>> Very cool.  Let's see.  I'm going to cherry pick this one.  Do you provide the developers code or does each team create their own code based on the design speck?

>> We have an awesome design system team.  A lot of these designs that you see here are made up with the design system components.  We have a huge library.  The team has worked to create parody between Figma and the design -- coded design system.  So they also work closely with a lot of the accessibility advocates at the company to make sure that when those designs are coded, they are accessible.  A lot of maybe keyboard functionality is already baked into those components and part of the library.

>> All right.  Let's see.  Where is that question?  Here we go.  This one is pretty popular as well.  How do you approach revisions to the components in the library and how do you update the designers and developers on what was updated or change?  Version and change management question.

>> Sure.  If you are familiar with publishing libraries and Figma here you can see all of the versions of the components they are put into variants like I mentioned here.  And I recently just updated this.  They were just kind of nested components.  Any time you make a change to the variants or symbol in Figma there's the library icon tool.  All you do is hit publish.  You can see we're hard core library users.  There's hundreds to choose from.  You can public that.  When you publish it, it will automatically update the files that other people are using the same library.  Their components will automatically be updated.  We also are big slack users at Indeed.  For things like the design system or when I announced I made them variants.  I just posted in are you S channel and ally channel and to say there was an update.  We kind of -- it is like ad hoc broadcasting.  But the way Figma manages library in Teams is chef kiss.  Really nice.  They will automatically update in your file.  Occasionally that breaks it and we try to be really cognizant of breaking changes and especially announce that to people.  Probably before we publish.

>> Great.  Okay.  Here's a really popular question.  I'm curious about this one as well.  How did you get funding for this project and how long did it take you to complete the entire project?  Complete.  I'm sure it is ongoing.

 

 

>> This is one of my personal pet projects.  This is something I wished I had.  So I was like I think I'll go make it.  I mean Indeed is just a really wonderful company to work with.  If you think something should be made, we have a lot of hack-a-thons, and even project teams are kind of in charge of deciding what they should do on their product or what the team should be doing.  So as someone interested in accessibility and designer of the company, I just wanted to create the tools and kind of free time and my availability put this together.  Oh my gosh.  I'm sure Christine is listening.  She will keep me honest.  I would say from initial conception and documentation probably -- because we already had a lot of the guidelines rewritten, I would say two or three weeks.  Then it is just ongoing maintenance.  Adding in components for list elements and tables.  That wasn't something that we discussed before.  We can add that in as time allows.  So we're sort of a do things go fast get permission later as I'm sharing this and it is not like legally publishly available yet.  Yeah.  That's kind of how we roll at Indeed and also another perk and benefit of.

>> Very goo cool.  I think my CEO might be listening too.  We do that as well.  Here's a question that has come up a couple of times.  And I -- I know a little bit about this.  I don't think I'm allowed to speak to it.  Maybe you can.  And that's -- accessibility of Figma itself.  Do you have a read on that or can you talk at all about that?

>> Yeah.  That's a really good point.  I don't -- I do a lot of screen reader testing and just try things out.  I don't think I've ever tried to do Figma screen reader and I mean I think unfortunately just historically design tools have probably been geared to -- you know, just not catering to probably specific audience like audiences like people who might have visual disabilities or impairments, things like that.  So I can't personally speak to Figma's accessibility.  That's a really good question.

>> Yeah.  We'll say I know they care and are looking at it.  I can't say much else.

>> Yeah.

>> It is definitely something on their awareness radar for sure.  So that was a great question.  Another fun one based on your library, how much time in your day is spend in Figma?

>> The design system team would laugh at you.  I'm going to Zoom in so you can check out the keyboard tables.  They are really fun.

>> This ties into some chatter in the chat as well.

>> Cool.  How much?  This depends.  I'm a UX design lead at Indeed.  I would say my day is split between Google making presentations in G slides, being in Figma, and sitting in a million Zoom meetings.  It is probably broken up like that.  All of the awesome user sessions that I get to watch.

>> Very cool.  Yeah.  That's certainly important.  This is all great.  You got to see people interact with it.

>> 100%.

>> This is a good one.  Did you encounter any pushback with the rollout of thaccessibility guidelines or the library?

>> The library, no.  Accessibility, we tried to make it a thing at indeed.  Ultimately the company is like OKR metric driven.  Until that mandate from leadership and making accessibility part of our quarterly, okay, our goals and things like that.  Until it was part of that product management process and kind of how things work at company.  Teams wanted to be accessible, but just they couldn't balance the workload of being accessible and trying to meet the goals that were set.  Until accessibility was prioritized as a goal through the awesome work of the diversity inclusion and belonging team.  That is how -- that was the kind of pushback that we got.  People wanted to do it.  People understand why being accessible and inclusive was important.  No one wants to be the bad guy that says you can't use my web site.  Especially because we care a lot about our job seekers.  It wasn't prioritizes.  Getting buy-in from leadership and having leadership understand why accessibility is important and why you have to do it immediately or yesterday.  A lot of it comes down to no one wants to be sued.  No one wants the bad press that comes with being sued for the lawsuits.  As well as it is just, like, the right thing to do.  It is going to save you money in the long run as well.  When it comes down to the business brass tax.  It is the right thing to do.  When leadership says to do it, people are incentivized to do it.

>> Okay.  Let's see.  We have time for a couple more.

>> I talk really fast.  Here's a question what are the things that you mark to hand them over to the designers?  Heading and tab and region.  You spoke to this a little bit.  Maybe elaborate on that.  Does it all account in the single page or multiple pages?  And I'm deciphers if that means the annotations or the information that you are handing over.

>> 

  

  >> Yeah.  It could be quite a lot.  If you had all of the annotations on at once.  Designers handle it differently.  Some people will have multiple copies of the page or file or flow.  They might have one that's specifically has traditional red lines that shows things like margins and specks calling out the specific colors and things like that.  And then next to it they might have, you know, here's all of the labels and things here's kind of what should be a button and something that we've included in any of the interactive stuff like links or buttons are the target area components so you can specify if you have a 32 pixel or 24 pixel icon that you can have a proper 44 pixel target area around it.  We want to communicate that to developers.  And you could have that in different panels.  Something that I like to do and had in sort of the example documentation was grouping each element.  You'll see the components group here.  I would put in all of my headings and group my headings to turn on and off the visibility of those.  Depending on what part of the design and content the developer was working on, they could turn on and off those individual layers.  In the description of how to use this file, it is really -- whatever is necessary to communicate.  You don't need to always -- you don't have to indicate every element.  It is really like where is something that might need special consideration?  Can we be more thoughtful or intentional with custom components do I need to include this is what and how the keyboard should work with it and this is the focus order.  As necessary.  Really just a starting point for designers and developers to talk about it.  If this is more of them talking about accessibility, that's a win in my book.

>> Absolutely.  We're at time.  I want to squeeze one more question in.  I think it ties all of this together.  This is from Phil who says so that you mentioned your approach to the usage of the accessibility library is use it or don't.  Is this because you are confident that word of mouth will be sufficient to see high adoption levels or something else behind that?

>> I mean I think no one wants to be told what to do.  I think if you build it, they will come.  No one was doing it because they didn't have an easy way to do it.  There's a psychology theory the more difficult something is the less they want to do that.

>> Right.  Right.

>> How easy it is to do it and how motivated I am.  If there's a lot of motivation to the accessible, people were doing this on their own.  If they weren't motivated and it wasn't easy to do, it was just being skimped.  Just making it easy and now that they are kind of expected to be held accountable, this is just another tool they can use.  It is not -- I mean I don't know if people use it or not.  I can still sleep at night.  It is just one of the many things we try to make available and improve about our practices.

>> Awesome.  TV >> With that we're not only at time, we're closing down the Axe Con.  Thank you to everyone that attended.  You took your slides down.  Your Twitter.

>> One moment.

 

Designing Accessible Games

Type: Breakout

Track: Design

Designing accessible games covers a lot of the same principles as designing for the web. But as a highly interactive medium, there‚Äôs a lot to consider in how to make a game accessible to your users. In this session, we‚Äôll go over techniques for designing accessible games, including color-contrast, subtitles, and remappable controls. We‚Äôll also be talking about game difficulty and how to provide different levels of difficulty based on your users’ needs (while still being true to your intent). You‚Äôll walk away with a solid understanding of the principles of accessibility in games and how to design your games with accessibility in mind.

 

 

>> We're going to get started momentarily.

All right.  I think we're going to go ahead and get started here.  Thank you, everyone, so much for joining.  This has been an absolute thrill.  I'm Josh McClure from Deque.  I'm going to be moderating designing accessible games brought to you by Stephen Lambert.  Virtual round of applause please.  I'm going to take care of a few house keeping things.  Today's session is being recorded.  And it will be hosted on demand for registrants.  The slides are currently available if you look down under this video feed there's a link to download the slide to follow along.  We're also going to have live captions that is listed below.  Definitely stay tuned.  We're going to save the last ten minutes today for Q & A.  Most any questions that you may have in Slido's chat.  Definitely join in on the conversation.  Share your experiences and thoughts.  I would love to hear from you.  With that, we're going to go ahead and start.  Steven, all you.

>> Thank you for being willing to come.  Second to last presentation on the last day.  I know it's been a really long past couple of days.  I'm glad that you took the time to come to this one.  This is designing accessible games.  We're going to talk about techniques for color contrast, and controls.  We're talk about game difficulty and different levels of differenty based on the user needs and still being true to the games intent.  I'm Steven Lambert.  I'm a senior developer.  I love creating games.  My e-mail is  Steven@SKlambert.com.  You can go find me afterwards.  Connect.  I would love to hear from you.  Also if you would like not only are the slides downloadable in the PDF form, there's a Google Doc at the Bitly.  You can get to here any time.  So like I said I'm a developer.  I love developing in HTML5 and Java script are my primary tools.  As a side project I developed a couple of hobby and things like break out or ramp heart.  I did Pacman recently.  I'm working on my first commercial game called Keridwen.  There's a free puzzle that you can play.  So that's all about me.  Let's get into what you came for which is designing accessible games.  What does it mean to make a game accessible?  This goes beyond just adding keyword support or screen reader information.  What does it mean to the players to make a game accessible?  So that means that for the player we are allowing them to play your game in a way that works best for them.  There are four common problems that stop most players that playing a game that works best for them.  These are taken from something called a game accessibility guidelines.  There's also a favor topic which is game difficulty and accessibility.  That appears every time a very hard game like dark souls comes up.  And everyone talked about how difficulty settings is and is it true to what the difficulty game should be.  We'll go over that in the end and talk about the fun stuff there.  First we're going to talk about controls.  Remappable controls are one of the best value accessibility.  This is a direct quote.  It allows them to use whatever setup that works best for their needs.  Players can play with the sticks, one-handed, and Xbox accessibility and custom configurations with buttons and foot pedals.  They can play in a way that works best for them.  You should provide a way to remap all players actions.  Lets player map the actions in the most convenient position on whatever setup they have for them.  We have an example here is an image from the counterstrike global offensive.  They are controlling the map settings which allows every action the player can prefer can be remapped to the different control.  Things like walking and shooting and aiming can be remapped.  Going beyond just actions in the game if you have any hot keys in your game which is very common for realtime strategy games.  You should also provide a way to customize the hot keys as well.  In the example we have star craft two.  You have a screen of all of the different hot keys that can be used for the play person it allows you to remap each of the hot keys for the building actions or the unit actions to fit your needs.  Here we have a great example.  This is over watch.  There are many different heros that have their own play styles and abilities.  The overwatch allow you to remap the individual character settings and better suit the play styles of each character.  This also includes in the image not only actions but things like red cool and change what you want for each individual character.  It is also important not to forget to change the in-game prompts.  We have the Batman image of the letter A prompt showing him what he can do.  A game that didn't do this quite so was a Lego Ninjago.  We noticed when you switch to co-op and played single controller none of the tutorial prompts showed it changed position.  It was still vertical.  We had to figure out the right button and bottom button because the controller was different.  And now players can often switch between multiple inputs during the game.  Common between switching between keyboard or controller or game pad.  You can use both at the same time.  You should allow all actions to be remapped between the keyboard and controller as well as mouse inputs as well.  And in the game no man sky pictures here in the controller settings they have a column for keyboard and mouse as well as separate columns for all of their actions.  Part of the control settings is to also help with the sensitivity of those controls.  You should allow users to adjust sensitivity of mouse movement or controller configurations.  This includes not only the mouse movement and things like camera movement and dual stick controllers as well as controller rumble settings and juice effects.  If you are not familiar with the term juice effects, that's things that we add to the game for the feel.  Screen shake or camera bloom.  Those things should also have their own settings to help the user.  Lastly you should provide options.  If you can simplify it to maybe just a few buttons, that helps a lot of players.  You should allow to change between things like press and hold to toggle or skips quick time events with just a single button press.  This should include ways for a user to play with just a single, one-handed controller rather than having two dual stick controller setups.  You can just map things.  A great example of this was the new Spider-Man game.  This simpler control screens and being able to skip them can benefit users who experience fatigue or strain injury or other types of disability use that needs them in order to play comfortably.  To recap we want to allow players to map the controls and don't forget any end game prompts.  We want to allow them to change the sensitivity and allow for simpler control schemes or skipping for realtime events and toggle to press.  Next we want to talk about for face accessibility.  The first and most important key to interface accessibility is don't make your text so smell they can only read it when it was on the computer screen a foot away.  The new game had a problem.  Their text was pretty small.  It was hard for a lot of players to be able to read it.  Especially when they were sitting on their couch 10 feet away from their TV.  They came out with a patch to fix the problem and improve it.  It only helped a little bit.  So Amazon TV has a good recommend that they use for captions that we can apply to text in the game.  It is about 20 pickets font minimum for viewing 10 feet away at 1080P.  You should increase the spacing between the sentences as well so your text message is also important.  In conjunction with a legible font size you should also have an easy-to-read font that's sans-serif, mixed case.  That's not to say you always have to have an easy-to-read font.  If you allow your users to customize the font, that lets them decide what's legible to them.  You can keep a personality in your game with a nice unique font and provide an option to replace the font with a much simpler one, if the user so designs.  Another way to help is add options to increase the font size or interface or hud.  This includes things like font size and prompts and images used for the game and borderlands and the font size and everything in the game that you could interact to increase as well.  You can also add options to customize the UI style.  Capacity and color and you can go further and customize position of the UI elements.  They are common in games such as MMO and RPGs.  You have lots of information in the screen.  And this is in the hud for the fall out fort.  They have settings for the RBG scale and as well as the capacity.  To recap you want to use large, easy to read font in your game.  You want to design that from the beginning.  It is always harder to implement larger font if you didn't take it into account later.  You want to customize the font size and style for users.  You want to be able to provide options to customize the UI in the position or size or style or capacity.  Next we have color.  Let's first talk about color deficiency.  If you are unaware, a red, green color deficiency is the most common form and affects about 5% of the world population.  There's a high probability that someone in the call or watching the video has a form of color deficiency.  The key takeaways is colors tend to look similar if you have a color deficiencies.  Reds and greens and oranges could look yellowish or pinkish and really green could look blue.  The most important thing is all means of color is lost when you have a come already deficiency.  We have the example of the match three game.  If you have to match three squares of a similar color in order to clear the board.  In the bottom right corner it is full color.  You can make out the different colors like red, green, blue, yellow, purple.  In the top left it is shown in the same image but with a Deuternopia.  All of the shades look the same.  Good luck being able to match three colors if all you can see is go out of the five that are shown.  The important takeaway is don't use color alone to convey meaning.  All meaning is lost if you can't perceive the color.  How do we make that work for games?  Well, first we can add a non-color identifier.  Such as an icon or pattern to distinguish between the colors.  Here we have a couple of images.  We first have the game Hue.  If you are unfamiliar it uses a color wheel for the color of the game itself.  That will reveal different things.  Either a door blocks your way and change the color to make the background the same color as the door and the door vanishing and you can walk right through.  To help with color deficiencies, they added similarrables to each of the colors and all of the objects.  Instead of having to color match, all you have to do is symbol match.  We have the game faster than light.  When your ship is damaged in certain areas or not enough oxygen, it goes from light red and darker red shade.  Enemies health of people that can board your ship and you have the crews health and the crews health was green and the enemy's health was red.  They enabled color deficiencies instead of being a shade of red to a darker red they had patterns.  They had alternating colors of red vibes to help indicate the level that it was.  They applied a pattern to it.  They changed the enemy health to blue to help distinguish between a red/green color deficiency.  Not only do you have good colors, they contrast well against the backgrounds.  This includes the text colors.  The common recommendation was 4.5 to one.  They had the world that was dark tile and lava and volcano and part of the objects were spikes.  It was a dark black.  The background was light gray.  You could kind of make them out.  The harder part is when they are down.  There's a red square in the top right corner.  You can barely make it out there are some spikes that are sitting in the ground.  If you weren't aware of that, that can cause you problems in trying to solve the puzzle.  This is very important that you keep in mind the background to the game.  Something that you can do is provide an option to change the contrast.  This is epic Eric.  You you can add an black layer between the background and foreground elements.  You can adjust how the capacity of the layer.  You can also make it completely white.  That can allow your users to determine what looks best to them in the background to help contrast with the foreground objects.

Another example is to just remove the background completely and make it black.  And street fighter four they had the option where you could just disable the background.  Instead of showing the colorful background of whatever world or arena, it just become a black box.  To help remove the distractions from the background and make sure the foreground players contrasted well.  Another option is to add outlines.  Here we see eagle island.  There's an image of the player who has wings on the back of the air.  He's shooting out the eagle.  And the player and the eagle he throws and the bats all have a thick, white outline to help them contrast against the blacker background of the cave.  Lastly if you want you can also just allow full customization of colors in the game.  This is more common in games that have distinction colors or teammates or enemies.  You can customize them.  They allowed full RGB for the enemy player and neutral player color.  To recap for colors, you can first don't use color to convey the meaning.  Use icon or patterns to distinguish between the meaning and colors for the players.  You can provide an option to decrease the contrast and provide options to customize the color ifs that makes sense for your game.  Next we can talk about subtitles.  There's a chance more players play with subtitles than you think.  More 60% of the players, turned them on.  They were turned off by default.  60% went to turn them on.  Because of that, they turned them on for default.  95% of people left them on.  As the game industry, we don't always do well with subtitles.  Start with easy to read.  Otherwise you end up with something like this.  I can't remember the name of the game.  They have very tiny text that I can barely make out what it says.  I'm right in front of it.  It is whatever the caption the person is saying.  It is possible to read.  Or you can end up with problems of contrast.  In this game there's a room and a main lobby of the hotel.  Somebody is saying something about the staff.  It makes the white text completely disappear against the white windows from the outside light.  Those are very common problems we can encounter with the subtitles.  Instead we want to do better.  The best approach is to add a dark, transparent background behind the subtitles.  The other option is to add an outline to the white text.  Like the black outline.  It is more common in usually a better approach to add a black background.  Some players can't read the subtitle even with the background.  This is showing on the glass and the subtitles have a black background while the player is speaking.  Not only should you add the black background but a setting to change the opacity.  Letter players decide if they want it or they don't or how dark it is.  Also it is very important that we don't over run the screen with a bunch of text.  In the image it is one of the screens where the leader of the council is talking to your commander.  It is just a paragraph of texts that takes up the bottom third of the whole screen.  This not only makes it hard to read, but the scrolling text.  Instead use only two lines per subtitle.  About a max of 40 characters per line.  The game hit man did this really well and one of the hit man levels and the person talking about hit man's goal and objective is just two lines of subtitles and 40 characters we are line.  Then the next time they talk they will update the subtitles.  Also when a player is talking or character in the game is talking, you should show the characters name.  As they continue speaking, you can drop the name for future blocks.  It is assumed they are continuing to talk.  As soon as a new market starts talking, you'll have to show that characters name again.  That lets the person know that a new person is now talking in the subtitles.  Again a game that shows this is showing a police officer talking and his name is Redwater.  In the caption it says REDWATER:

It covers more than just spoken words.  They provide a lot of information through audio cues.  Things like enemies yelling they threw a grenade or player with a special ability or gunshots happening in a person direction.  They should be conveyed in subtitle.  The players can receive the same audio information that others received.  The game half-life two in the image did that really well.  In the image they are shooting a bunch of things in the ware house or garage.  And the captions not only show the person being talked to, but also shows things like shattering glass and pistol shot or they can't use sound so that someone knows the thing they are trying to interact with isn't useful.  That information should also be conveyed to the player.  Going further we can also add direction to our audio sources.  Here we have Minecraft.  If you are walking across the ground or swimming in the later or something else is swimming in the water, they will have a caption to the left or night.  Fortnite which takes the 360 around the player and shows the sound that it came from.  You know exactly about where it came from and they go further showing an icon and the color of what that sound was.  Whether it was gunfire or foot steps of things of that nature to help make sure if you don't have the sound on for whatever reason or you can't hear it, you get the same information that audio cues provide.  Of course when in doubt, TV standards have been doing captioning and subtitles for years.  They have lots of standards.  Go to the BBC.  Netflix has their own guidelines to go to read more about how TV handles the best practices to subtitles.  So to recap you want to use large, easy-to-read text.  You want to keep your subtitles to a few lines of short text each.  You want to show the speakers name and you want to caption the audio cues in your name.  Last we're going to talk about game difficulty.  Now game difficulty can be a controversial topic.  Some players like difficulty and don't think a project is less difficult.  Other players want to play difficult games, but they aren't able to, because it is too difficult.  The common argument is they shouldn't include the difficulty option because it keeps to the creators intended way to play.  I'm not going to talk about any of that.  We're going to try not to be controversial here.  We're going to focus on what difficulty in the game means and why it is important to a player to have it.  So first I'm going to misquote Keita who said games can be as difficult as they like so long as they are fun.  What exactly do we mean by game difficulty and being fun?  When we talk about game difficulty, what we're actually talking about is a single access of a graph of a players experience with the game.  So we have on one axis is the difficulty on that game.  On at the other is the skill or ability of that player.  So when compared to the players skill and ability if the game is too challenging for the player, they will experience frustration.  They will have a greater chance of just stopping or abandoning the game because it is too frustrating.  But if the player skill or ability is far greater than the difficulty, you'll experience boredom.  And they have a chance to stop playing at the game because it is not enjoying or difficult for them.  So what we have then is the very narrow channel in the middle between the difficulty and skill ability that we call the flow zone.  The flow zone is where the player is neither overly frustrated nor overly bored.  What we want is the player to remain in this flow zone.  When the game presents the difficulty that's just above their skill level.  They learn to meet that challenge and get a new difficulty that keeps them in the ebb and flow of the flow zone.  The flow zone is not just a straight line.  It is more of the curve up and down between thing that is are difficult and their difficult and difficulty in the game.  When we talk about game difficulty, what we really want to be talking about is the relative challenge to the players current skill level.  The reason for the challenge can be due for the physical or mental disability or for the player reaching the top of what their skill level is.  No amount of play or practice will get them beyond that ability.  If it is too difficult, they become frustrated.  They abandon your game.  The goal of any game should be to keep that player in the flow zone.  Present them challenges that they can over come no matter what their skill level is.  How do we keep players of varies skills in the flow zone to avoid challenges they can't over come.  One thing you can do is so some form of difficulty options in your game.  These are different settings that say easy, medium, hard, or some of the things that will cater to the skill level those players need.  We have an example of the old game Doom.  They have an option screen for skill level from the top down from easy to harder.  I'm too young to die.  Ultra violence.  And nightmare.  Don't make fun or belittle your players with your difficulty options.  It doesn't help and it is not funny.  It will only make the players upset who need to choose those options for them to enjoy the game.  You also want to give the players the right expectations for those different difficulty setting.  Don't just list it out.  What does hurt me plenty in terms of the meaning of the difficulty the game will provide.  I don't know.  I have to soon because it is at the top the bottom one is nightmare.  Nightmare sounds rough.  Top must be easier.  You should describe what difficulty option can change in the game.  Whether that's enemies get more health and do more damage or less damage.  In this example we have an imagine of the game.  When you start a new game it has four different options for difficulty, we'll say.  The first survival.  You can also have a game called freedom.  That removes the health and -- it removes the food and the water need and keeps you with just health and oxygen.  Then you have another one called hard core which adds all four and adds permadeath.  That's creative.  It has none of the options.  You don't have to worry about them.  It is very obviously what each of the settings will change to help you as a player decide what it is you want your play style to be.  You don't have to think of difficulty in terms of different settings like easy, normal, heart.  You can just have a group of settings.  In the game Celeste, there was an assist mode.  You can change the game speed and whether you have visibility or not.  These were amazing.  Because these four options alone for Celeste which is a very difficult platformer game would allow lots of different people that wouldn't play to play.  I'm going to play a video for a minute.  We're going to watch someone use voice control to play Celeste.  They are not using a keyboard or controller.  Just voice.

>> They have the ability to play quite a bit more quickly.  Yes.

>> Right.  Jump six.  Up.  Jump.  Jump.  Jump.  Up.  Front.  Dash.  Right.  Dash up and up.  Run and jump.  Okay.  In the video we saw the player going through the beginning of levels and it has them do a bunch of different long jumps and dashes.  There's strikes on the ground.  Because the player was able to turn on the invincible and because they could have infinite stamina, they were able to use the voice controls.  They weren't perfect.  They had a lot of spikes.  For the player that couldn't play the game as it was written for the normal controllers, this allows them to play.  It was hard for them.  This was their first time they were able to get in under five minutes.  They were trying to play as fast as they could on the level.  It took lots of tries.  I think it was to to 30 tries.  With these settings to do that.  Game difficulty settings allow players with all sorts of abilities to enjoy the game at a level that works for them.  And you can also not only just have individual settings, but customize different aspects of the difficulty and create their own experience through configurable settings.  This is called passive fist.  They have individual controls for the enemy strength and how much encounters that you'll have and how much -- the combo master that you need to get and resourcefulness.  Excuse me.  How much resources, I think it was that you can encounter.  Each of those can allow the player to choose the difficulty for them.  Of course difficulty settings don't have to be sliders or switches.  You can think outside of the box.  In the example is super giant game, their difficulty settings were the idols or the lenders and other games that you could enable at any time.  They increase @ difficulty of the game in the single aspect making enemies harder and making more health.  You could mix and match those different difficulties to create the experience that you had most fun with.  Of course doing that also then rewarded extra experience points for the users.  It gave them an incentive to try things that were harder to increase that difficulty.  Here are just kind of the short list noncomprehensive of different examples of difficulty settings.  You you could have a practice mode or allowing players to go and over and over and over.  Think about the road where you have to go many, many times in the first part just to get to the later parts.  If you keep dying at the later parts, then all you have to do is the beginning parts over and over and over again.  So your skill you can master those beginning parts really well.  You'll quickly become bored of them.  It is the end part that you need well.  20 minutes of things that you mastered can be really boring.  That can help someone.  You can have an exploration or story mode that removes all difficulty settings and just for them to have fun and explore the world.  Great for dialogue heavy where the action but more of the story progression is the theme.  Things manual save points allow them to save right before tricky things and be able to reset right to the point without having to go through all of the other stuff that they did.  World skips and sort of like a world save but allow players to skip to different parts quickly if they've gotten and done the beginning.  There's also adjust the game speed.  Make it faster or slower to help give people more reaction time to what they are doing.  We saw that in the  Celeste video to say their input.  Invisibility is a practice mode that lets players have fun without worrying about death.  You can increase their stats giving them more health, more endurance, stamina, or do the same for the enemies.  Give them less health.  Any of the numbers that your game has to determine what happens, you could make a difficulty setting.  It is great about difficulty settings is that players will naturally play at a difficulty above their skill level.  That's because that's where the fun is.  Players don't want to be bored.  They don't want to experience frustration.  They find what works best for them to experience the game in a way that's fun.  To recap there's a lot of information.  Provide difficulty options for your players.  Allow players to fine tune their experience.  You can -- through different difficulty settings or have more settings that expose different knobs.  Think outside of the box.  You don't have to do sliders or you don't have to do different settings.  You can have things like super giant games.  If you want more information, go to gameaccessibilityguidelines.com and accessible.game/accessible player-experiences.  If you haven't heard of him he does fantastic game design and taking current games and past games.  He did entire series on accessibility in games.  He can further get more information from.  All right.  Let's put that all in the practice.  Let's try to make it a game accessible with just a couple of minutes that we have left.  Here's Arkanoid.  It is like breakouts.  You have a ball on the bottom of your screen that you pass off to hit different bricks.  The bricks have different colors.  The colors represent the points that you'll get for knocking them down.  And sometimes those bricks can't be knocked down.  The color like the gray ones you can't use the ball.  They will bounce right off.  They don't break.  So what -- everything that we've learned, what are some things maybe we could do to make the game more accessible?  So first we could, you know, applying the color contrast and make sure that maybe that light blue brick color doesn't contrast really way.  We can change the color of the brick to make it contrast better.  Maybe we could have an option for the darker overlay to make the blue standout of the brick better.  Because the bricks have different colors that represent different points or whether you can or can't break them, we should also make sure those colors aren't their own way of conveying those meanings.  Maybe we add icons to each of the bricks or color pattern that help let the player know which bricks they can break and which bricks they can't break.  If we were talking about controls, maybe the game was designed to use WASD.  We want to make sure to allow them to do something that works best for them.  Things of the nature.  We can also make sure they have some enemies on the top of the screen.  It is hard to see as well.  They are multishaped circular blobs.  They don't stand out so well.  Maybe we add a white outline to the enemies to help them contrast.  This is a very old game.  There's lots of things we can do to help improve it.  Let's try a more modern game.  Breath of the wild.  Here they have a puzzle.  Where you have to make -- if you are familiar with the old Marvell game labyrinth.  You have to take the knobs through the game.  Zelda did this.  We'll make you familiar.  They had the player example the puzzle and then they have controls which are tilting the entire game itself.  The switch pad that you'll tilt that and that tilt motion is reflected in the labyrinth puzzle moving the marble and the blocks and the circular orb that you are trying to get to the end goal through the game.  There's lots of little holes and no walls on some of the edges that you can follow through.  So what could we do for this game to make it more accessible?  Well, for one because the game relies on the input to tilt to move the labyrinth.  We can make that better.  If that doesn't work, let's rematch the controls to the arrow keys or the controller key pad or thumb stick or whatever.  Make sure if the player isn't able to tilt, that means they can still play the puzzle.  Other things we can do is maybe the walls aren't exactly the most apparent.  Make sure they have good contrast against the background.  Make sure the player understands where the walls are.  Maybe we can help them again add an outline to the walls so that players understand where the boundaries are compared to the game and floor and the outside.  If the -- they did a pretty good job there.  The ball is a bright orange color.  You can see it against that background.  There's always something.  If we look a game, I'm sure there's something we could do.  Maybe the font size for the control captions is pretty small.  We could have an option.  There's all things we can do.  If we look at the game from the design point of view and keep all of what we learn in the session in mind, there are always ways to improve the accessibility for someone to help them play a game that works best for them.  We're going to end five minutes early.  If you have any questions, post them in the Q & A chat.  If you want to connect with me, there's my contact.

>> Excellent.  That was so good.

>> I developed the HTML elements that mimic what the game has itself.  If you are using unity or go dot or whatever the game frameworks, they may have their own tools.  You'll have to go investigate.  I'm not familiar with all of them.  Specifically for accessibility.

>> So what you are saying is this sounds like an opportunity for somebody out there, the community, to build some tools; right?

>> Probably.  I only development in a couple.  I know there's lots of tools.

>> I'm with you on that.  That's awesome.  So I think we are right at time, everyone.  I'm sorry we couldn't get to every single question here.  There were so many great questions.  Each out to Steven.  He has his social profiles linked there.  Do reach out.  We would love to hear from you.  Thank you so much, Steven.  That was great.  I really appreciate everyone joining today.  Thanks.

>> Thank you for having me.

 

Micro Interactions, More like Micro Aggressions

Type: Breakout

Track: Design

For a Neurotypical person, an attention-grabbing, movement driven feature can be a friendly nudge alerting to a new enhancement or a welcomed hint that a chat is available if they have questions. Unfortunately for someone with attention-related disabilities, or Neurodivergent, that distraction can and often is the end of the road for a task. With the popularity of micro-interactions on the rise as mobile technology continues to grow, the barriers they create for people with attention-related and other cognitive disabilities rise along with it. In this talk Shell Little will discuss the difficult place we are at with these standard-less patterns that help some and block others using a variety of examples including in-the-wild patterns with a focus on mobile-based micro-interactions, all to answer the question ‘what is micro enough?’.

 

>> We're going to get started soon.  Thanks for your patience.  We'll get kicked off here shortly.

Hello to everyone that's already in the chat from all over the world.  That's really exciting.

Once again thank you, everyone, who is trickling in here.  We're going to get started in three minutes.  I'm Travis Marsca.  From Deque.  There are some questions about the availability of the slides.  Are those going to be available?

>> Yes.  I plan on making them available after the event.  I'm slow at getting slides out.  They will be.

>> No problem.  I wanted to be able to answer that.  We're about two minutes from start time.  Let's go ahead and go over a few things.  Again thanks, everyone, for joining.  My name is Travis.  I'll be your moderator.  We have Shell Little your speaker today.  Just a couple of housekeeping items to go over today's session will be recorded.  You'll have access to that as attendees as soon as it is available.  The slides once they are available to us and we make sure they are access will be up on the session page.  Just a little bit about the user interface that you are interacting with.  Just to the right of your video stream you'll see the Slido component for Q & A and chat.  A lot of you are already interacting in the chat.  For questions that you want us to get to at the end will be -- I strongly recommend the uploading feature so we can get an uploading feature to get an idea of what the most popular questions are.  We've got a lot of people here.  I'm sure there are going to be a ton of questions.  That will help me get the right questions asked.  If you would prefer to use captions, that should be depending on the size of your monitor below your video screen.  You have to scroll.  I encourage you to interact with that and adjust the font size and things like that to your liking.  I think that's about it.  Feel free to interact with each other in the chat.  If you have questions that you would like to be asked, use the Q & A portion of Slido.  There's also a couple of settings there if you want to filter by most popular or most recent based on your preference.  And right half past I'm going to hand it over to your speaker and go off camera.  Thanks, everyone, for joining.  Shell, take it away.

>> I think you are muted.

>> I can just give a talk to myself in the house.  Thanks.  If you are looking at microinteractions at the right place.  Without further ado, I know there were other talks that you could go to.  I know it is late on the east coast.  I appreciate that.  I want to note that.  I really do.  Let me start my timer.  And we're off.  Cool.  All right.  So when I give talks I typically like to have a road map.  This is setting expectations for the talk.  On the screen I have my road map.  The first bullet point is intro, microadepressions, number three is standards, and number four is microinteractions, and then the last can conclusion.  On the collide numbers, 1, 2, 3 are quite close together.  A little bit after is four and 50% of the road map is going to be for microinteractions.  It to set those expectations.  Let's get going with the introductions.  I'm Shell Little.  I'm very active on Twitter.  I don't check my LinkedIn.  I work for Wells Fargo for the retail side of the bank.  I work in corporate.  If you go out and get a credit card, you are not working with my stuff.  In my job I'm on the accessible user experience team where I'm in the design and mobile lead.  I have a lot of cognitive disability and evangelism feels weird.  I live in Seattle.  I'm partnered.  My kids all have tails.  If you know me, I have ADHD.  If you don't know -- it is who I am as a person.  On top of having ADHD I have a lot of other really words that go with how my rain works.  I have a large set of words to show how overwhelming to have all of different names.  I have a traumatic brain jury, chronic migraines, nerve damage, time blindness, brain fog.  There's a lot of stuff that goes when you have a cognitive disability.  It is all bun thing and a myriad of others.  I like to say I'm neurodivergent.  What does that mean?  It is not cognitive challenged.  I am not challenged by my brain.  I'm challenged by Sod oku.  It is not cognitive defects.  I didn't come off of the line defective.  Not special needs.  They are what everybody has and everybody needs.  Let's remove those.  Now to move on to defining the term that means having a brain that functions in is way that's different than the dominant societal standard of normal.  Normal is relative.  We have statistics.  This is going by a neurodivergent activist.  Whenever I give a talk I have to talk about spoon theory.  You really can't understand what it is like having a cognitive disability unless you understand what spoon theory is.  Let's jump in to talking about spoon theory.  To define it, if you haven't heard it before, it is a metaphor created by Christine used to describe the daily amount of mental or physical energy a person has and the toll of being disabled has on energy.  Basically your spoons are a measurement.  They can only hold a finite amount of stuff.  They are a universal tool.  Being a disabled person living in an ableist world it takes more spoons to exist.  Not only does it take more spoons to exist as an disabled American an ableist world, you also get less spoons back from sleep.  It is all about -- it is a balancing game.  That's what we do as disabled people is we balance energy.  We balance our spoons.  On the screen right now I have a chart.  I'm going to tell a quick story.  We're going to pretend that you have ten spoons.  The first line is for someone that's not disabled.  It takes one spoon to get out of the bed.  That takes one spoon.  They work all day.  Job is pretty hard.  It takes three spoons out of them.  Next transit back home another spoon.  When they get home at night, they have four spoons left to pay bills, make cool, grocery shop.  Pick up the kids.  When they rest, they are back to ten.  Now let's talk about somebody who has chronic pain.  Potentially nerve damage.  Morning routine showers suck and hurt when you have water running over parts of your body that have nerve damage, it hurts.  Getting up and getting move can be difficult.  Transit is difficult.  Someone bumps into them on the bus.  They are uncomfortable and jammed.  Feeling anxious.  Work it is hard for them to get food.  All of their co-worker's go out.  They are having a high-pain day and maybe they have to order food or go out of their way.  Transit home.  They had a rough day.  Instead of just taking transit home, they pay for a Lyft to go home.  To save spoons they had to spend money.  Next when they are home, they don't have any spoons left.  They have one left after the day.  Unfortunately they don't have spoons to pay bills or do laundry.  And they have to order out.  So again they have to spend more money to save spoons.  Because they had a high-pain day, they get 7 spoons when they rest.  Being disabled is expensive.  It is hard to take care of yourself and make sure you are giving yourself everything that you need.  Ability is a sliding scale.  What you can do in the morning and what you can do at night are little things.  I had two into graphics on the screen what you can do in the morning versus when you get home and you are drained after being bombarded with the cognitive strain and the lights and sounds and feels and the tastes of, you know, being outside and smelling the air.  It can be a lot for people with cognitive disabilities.  What you can do at the end of the day is quite different.  My barriers come from purposeful design.  My barriers come from the design decisions.  The biggest one for me is movement.  In the morning something that's bothersome is a poke.  At night it can feel like a slap.  I'm trying to pay bills.  In morning.  It is easier especially medication windows rather than at night.  To quote Jamie knight from a couple of hours ago, distraction is a process that builds on barriers such as memory and decision making.  Distractions can quickly stack into an unrecoverable barrier.  All righty.  Let's move into microaggressions.  When we have the barriers, we're being pulled and pushed.  It is draining us of spoons.  Microaggressions come into the play.  It is a statement, action, or incident regarded as indirect, subtle, or intentional discrimination regardless of intent.  Doesn't matter if you meant it or if you were trying to be nice.  Microaggressions is a common part these days.  When which is hard when you are part of the group of people.  I have a screen shot on it of a woman of color who is being just bit by mosquitoes.

The concept they push forward that I enjoy is microaggression is like mosquito bites.  It is not just one.  It is the fact that you get them all day.  It is totals up.  People grabbing at you and touching your wheelchair and grabbing your cane.  One is not the end of the world.  It is a systemic problem that builds until sometimes you explode.  In the disability space, you are so brave.  I'm just getting coffee.  I'm outside.  I didn't do anything brave.  I'm just ordered Starbucks.  You are too beautiful to be stuck in the wheelchair.  The person who delivers that believes it is a compliment.  It is one I get a lot.  They learn about my cognitive disabilities.  You are so articulate.  Thanks.  I have heard of friends who have disclosed and been told you are really smart for having cognitive disabilities.  Those kinds of comments are examples of verbal microaggressions.  They say you are welcome here and you are not understand here.  Who you are and what you represent is something that people don't get.  An example on the microaggression on the web is clubhouse.  There's an app called clubhouse.  People have been buzzing about it.  It is an audio-based app that has no room for any sort of the asistive technology in their minds for captioning or nothing for transcripts, and also the fonts are not adjustable.  So if you have low vision.  And according to clubhouse, it is done by design.  So they want to be elite and exclude on purpose.  You are not welcome here.  Another one microaggressions on the web when people use overlays that are not accessible.  You can not slap on Java script and call it accessible.  They went to the web site that's using overlay.  The screen reader is not working.  They are not welcome on the site.  Even though the person who got this is using an overlay thinks they are doing the right thing, it is still a microaggression.  I have screen shot just for a random sample.  For people with cognitive disabilities, the Internet can be a downright hostile place.  I know we talk about vestibular and people with seizures.  The Internet can be scary.  There's a type of microaggression that I would like to talk about.  So I gave a talk it was two years ago now.  2020 didn't exist.  But basically things that are to trick and manipulate users.  People with cognitive disabilities, especially people who are low on spoons are very susceptible and high risk.  It is considered a microadepression.  Hostile or hijacking patterns.  Pick me.  Pick me.  People with cognitive disabilities do fall prey to that kind of pattern.  Unavoidable motion and flashing content.  People with ADHD and attention-related and people with autism speak about how difficult the web can be because of those things.  Protection from cognitive microaggressions.  Read only mode.  Ad blocker.  Eric Bailey wrote a really great article for reader mode the button to meet.  It is a great one and has a ton of resources built into it.  People use things like ad blockers.  And so on the screen right now I have a screen shot.  We see her using an ad blocker.  I need an ad blocker to use the site.  Am I just not welcome here?  On the screen right now I have a tweet from a person saying sometimes I do want to turn off the ad blocker when a site that I like.  I want to support, usually I have to turn it back on.  The ads are too distracting.  I didn't have allocated space.  It slows everything down.  There's multiple reasons why people use ad blockers.  They are just not welcome on the sites.  Are they are doing on time?  Crushing it.  Sweet.  Next up we're going to talk about standards.  WCAG.  I have a love/hate.  If you know me personally, I have a lot of feelings.  I respect how far we've been able to come.  We need to go forward.  WCAG we only have a couple of standards.  A lot of them are AAA.  Cognitive disabilities are really complicated.  The biggest thing I like to tell people a fix for one cognitive disability is barrier for another.  And that's really true.  You can't do a one-size.  Fits all which is why inclusive design is so important.  Because you could be unintentionally creating barriers when you think you are fixing it for one user group.  Thinking holistically is important.  That's what standards are for.  They give you a testable solution or guidance.  It is really difficult to write standards for things that are so nebulous.  Looking at WCAG2.is my favorite.  I said I would get a tattoo of 2.2.2 on my body.  I guess I'm really overdue for that.  It is basically at the criterion that says moving stuff that starts automatically, last longer than five seconds, presented in parallel to other content has to have a way to be paused, stopped, or hidden.  Caveat being unless it is essential.  And the other animation related criterion is animation from interaction.  It is similar to pause, stop, hide.  Motion animation triggered by interaction can be disabled unless it is essential.  How relevant it is in the United States depending on your organization.  We always strive and push for AAA.  It is tough to test for.  When it comes to the standards there's just gaps.  That's just how it is.  Especially when -- anything that's essential to the function is exactly the rule.  But essential depends on who you ask.  If I'm trying to pay my bills, it is essential that I pay my bills.  If you ask the company they are paying bills, they might want me to sign up for a new service.  It is a new things, and they want new users.  For them me paying bills is a secondary.  They want me to sign up for the thing.  Next for the gaps can be paused.  Equals is it possible to do so.  Not you can continue and complete your task.  Can it be?  If that thing pops in your face and you have moving ads.  If you can close it, it passes.  Unfortunately with cognitive, it is the slap.  You are done.  There goes your train of thought and working member that you were holding on to that little bit of information in your hands gone.  Like I was saying dismissible animations and auto play.  You can dismiss them eventually.  I like to say where WCAG stops that's where the cognitive barriers start.  That a difficult place to be.  We don't have standards for microinteractions.  We bareically -- people barely respect pause, stop, hide as it is.  To ask and push us further to talk about microinteractions, I would really like for us to great at some point.  Which is why I wrote this talk.  All right.  We're at section four.  This is the bulk of the talk.  I'm going to jump into talking about microinteractions now.  Awesome.  Defining microinteractions.  It is any single task-based engagement with a device.  That's from Carrie Cousins.  It is a pretty, nice, simplified expression of what is microinteraction is.  Depending on who you ask, people have different opinions.  From UX design their definition is microinteractions are used to communicate meaningful feedback to users because a user has to constantly know what's happening when an action is performed.  So it is the dance between the user and the device or the -- or the computer.  When it comes to communication.  So from -- I never said their name out loud.  An end group, you know who I'm talking about.  I'm so sorry.  They had a good article about microinteractions and breaking it down.  There are microinteractions that are user based and microinteractions that are system-based.  Animations and things that happen when you interaction with the web site or web app or application.  It is either you are initiating them or the system is initiating them.  Basically they come in different forms.  Talking microinteractions in terms of the motion.  Next up is feedback and metaphor and navigation and signifier and attention grabbing and attention hijacking.  There are for things like communicating space changes and metaphors of navigation.  They are for the types of thing.

These are really important to people with cognitive disabilities.  I have sensory processing disorder.  I get tunnel vision.  When I need to do an action and the device is giving me proper feedback and it's done in a tasteful way, it really, really helps.  That's the tough thing.  What is too much and what is not enough for them.  Let's get going on breaking down the different uses of microinteractions.  First off feedback.  An animation is used to communication an action that has been recognized by the system.  It is feedback.  It lets you know the thing that you just did worked.  On the screen I have an interaction of what Spotify has on their like button.  You can like a song and it adds to the like play list.  For those of us who are sighted, keep focus on that.  The interaction, the heart when you toggle it off shakes.  When you toggle it back on, there's an animation of little hearts coming off of it and circles going outward.  It shows the user what be you just did worked.  It also has cute animations to say you liked it.  It is just a great example of what feedback is.  Next up is state change.  That's an important thing to communicate to the user.  It is used to communicate the action has been recognized by the system.  I forget to change the slide screen text.  Something has changed.  Something is different.  You need to be aware of it.  The example that I have on the screen right now is Twitter.  They have a blue button that's sticky on the bottom righthand of the application.  When you are on your feed it is a plus sign with a quill to write a Twitter.  When you toggle over to the messages, the button moves and switches over to the message icon.  Create a new message.  You can Twitter something to you are going to message someone.  To handle that, they have an action button.  I'm going to push play on that.  We'll check it out.  How it works is the button spins and toggles back and forth between the different settings and versions.  That's a state change.  We're going to move on.  Thank you.  Cool.  Spatial metaphors.  This is really important for people with cognitive disabilities as well.  Having animation to communicate the thing and mode is coming from the action button.  Those kinds of communications are really important.  On the screen right now I have just a menu from Google.  Just hitting a menu.  It is supplemental cues for the direction they are moving within a process.  Think about the phones when you swipe from left to right.  You have a cube effect.  It is just giving that feeling of transition.  I'm going to push play.  It is just a menu.  Like a hamburger menu expanding with animation.  Nothing too fancy.  It just goes out.  And it goes back in.  It is communicated the user the menu lives over here.  Which is important.  Awesome.  Next is signifier it teaches them how to act.  It shows them if you pull this, I'm going to do something, if you swipe this, I'm going to go away.  Thinking about Tinner and Bumble and you are able to swipe a card.  I have Apple music.  When you select the song it allows you to pull down and dismiss.  It gives the user that feedback to say I'm dismissible.  Last but not least attention hijacking.  This is a dark pattern.  Often times it is used for evil.  If you did not get Eric's talk today, it ties into the content for looking out for the dark patterns like attention hijacking.  It is a landing page of the video editing app.  I'm going to push play.  It is chaos.  Everything is moving.  There's an edit button that toggles.  It flips like a card over and has animation inside of it.  There's a crown that represents their premium shaking and moving.  Then at the -- they have some content sections below for creative videos.  They are all moving as well.  I'm going to push play.  It is pandemonium.  Getting on the page and trying to figure out what you are trying to do is difficult.  It is shining and moving and live edit.  It is so much.  That crown moving and bumping is like pick me.  Please pay me money.

Awesome.  Let's tie this into the cognitive accessibility part.  Cool.  Just checking time.  What makes a cognitively accessible microinteraction?  That's a great question.  After doing research, all I can say, it is complicated.  It is tough.  There are some things that you can look out for.  There are some points that you can takeaway when you are having to find a way to communicate to users that's good, because you are trying to communicate something important to them.  It is not too much.  So the points that I would like to talk about in the cognitive accessibility microinteraction stuff is relevance to task, size, location, speed, and intrusiveness.  Which is a word that I like.  So when it comes to relevant of task, asking yourself as a designer is the task that I'm asking at the user to do in the work flow or am I pulling them to the banners or to the rails on the side?  Is it relevant to what they are doing right then and there?  Is it something the user wants the system to know?  We have the new feature you'll probably never use.  We want you to know, because we worked really hard on it.  Those kinds of interactions can be jarring when you are trying to get something done.  When it comes to relevance of task, who determines what the task is when there are so many different things you can do.  Are you really going to pay your bills or check your credit score?  What are you trying to accomplish?  I had the thing that if I could look at.  Your task has changed.  Remembering you are not your user.  Access lab has a really great resource about tweets and stuff.  I snagged a couple from them.  One of them says assuming ADHD counts, it is hard to locate content or overly busy pages and animations are a nightmare of distraction.  In terms of distraction is it relevant to flow and task?  Is it user initiated or system initiated?  That changes a lot.  If it is something the system is doing rather than the user doing it, it changes the feeling of the interaction.  System initiated stuff, you are being pulled.  You are being yanked.  You are being called.  There's a bell ringing on the corner.  You are being pulled away.  You don't know where it is.  On the screen it has a channel point where you are able to watch and support a streamer and rack up channel points.  The screen box next to the channel box shakes until you act on it.  You have to click it and select it in order to claim your points.  It passes pause, stop, hide, because you have doing something with it.  What if you don't want to collect them?  I have another tweet on the screen.  Anything that moves without me initiating that movement is so distracting.  I'll be unable to read what I same to do on the site.  Basically the attention grabbing is to effective I can't use the site.  Is any of the stuff that happened relevant to your task at hand?  I highly doubt it.  Another example for wondered is the system applying to the action or you just being on the page?  I have a really bad screen shot.  I was angry.  I was on Jera.  This is a menu on the side.  They have a purple button or badge.  It has a ring around it that pulses.  It goes in and out.  I could not dismiss it.  I was trying to work on the ticket that was critical.  I've got the thing buzzing over here.  I really don't care about custom channels.  I'm trying to answer the ticket.  By moving it pulled the distraction and made it harder.  ADHD if there's a subtle animation running, I cannot focus.  Biggest offender is blog.intercom.com.  This is another I snagged.  Those kind of concepts.  Is it interaction something to help the user or pulling them away for something else.  That thing you were working on six weeks ago it is overdue or notifications, toast, things like that.  Not everybody wants those.  Next up is size.  Animation shouldn't take up more than one third of the screen size.  On the screen right now I have a lovely example of the restaurant web site.  It is not one third of the page.  It is everywhere.  This can be so jarring and it can make you ill.  I got dizzy taking the screen shot myself.  It wasn't great.  Animations cannot take up that much of the screen.  The thing is animations add up.  To size.  If you want to look for really bad experiences, go on mobile and look up any recipe.  Recipe sites are riddled with madness.  The screen shot has a banner that has pancakes and fluffy Greek yogurt.  Next is an ad for the car I don't want to drive.  You have the add choice maybe if you click that it will show the X button.  Maybe it won't.  Then there's part of the article.  Above is a pop-up add for makeup and beslow the Verizon.  Every single thing on there moving.  At the best part is on the right hand is to heart button to save it.  A heart button and you have to see it is updating.  Hearts shoot out.  It is a lot.  This web site is basically useless at this point.  Next up is location.  So how far are you from pulling the user from their task?  On the screen right now I have an add to cart and shopping cart.  I'm going to switch to the next screen which is animated.  When you -- in the example when you select add to cart the button shrinks and jumps over into the cart.  And badge comes up.  This is an example of right there with the user.  They are doing it.  It is showing them the thing that you just did has been simply add to the cart.  I've seen ones that go up and across the screen.  If you are adding 30 things to the cart, maybe the animation is not so great.  In general things like this that are in your proximity and work flow can be beneficial to users.  Next up is in terms of location is the animation and context with the content.  Is it a full overlay forcing the user to watch the screen and add.  It is not really in context.  It is annoying and jarring.  It takes you away from your task.  If you were holding on to the number or something, that's gone.  It is not in content or in parallel with the content.  So, you know, if you have to have something moving, out of context is way better.  Next is speed.  When it comes to showing, it is too fast.  The button pressed that changes state.  If the user moves too fast, they won't understand.  We had UXR for doing authentication processes.  We got feedback from the users the authentication was too fast.  They didn't believe it was working.  Because of that we slowed it down a little bit.  So users could think.  It is really thinking about logging us in.  It is really checking that security.  Because it moved too fast they were unable to see the load, and they didn't believe it worked.  On the flip side they will use that connection you are showing them with the microinteractions.  If you push the button to expand something and it is over ten seconds, user might forget they pressed that button or which one?  I can't remember.  In general the rule for hydrointeractions is typically one second.  300 or 400 milliseconds to give an instantaneous response.  This thing you did worked.  I'm loading the page.  One second still gives them a seamless experience.  There's a sense of delay.  The thing is thinking.  Ten seconds versus what I already would feel like five seconds.  They are praying to the Gods it is going to work and not going to crash and go through.  Studies have shown that anything plus ten seconds or anything user memory is way too long.  Keep that in mind.  Last but not least on the section.  I know I'm running short on time is intrusiveness.  Going back to the example of the switch thing.  Is it endless until the user interactions?  How easy is it dismissed?  If you have to be a hacker to put your hood up and sunglasses on.  I don't know.  Sometimes they have a hammer in their hand of people who are hacking.  You shouldn't have to be a stock photo hacker to figure out how to get your animation to stop moving.  Intrusiveness is how much effort?  Anything that interferes with my ability to see at the high contrast and highlights as I read makes the page harder to read.  A lot of custom UI widgets seem to interfere with this.  They are hovering over things and moving and popping.  Imagine if there are links in the text.  When they hover over the links, they are moving and popping.  Maybe it looks cool.  For this person that's a barrier.  On the screen right now I have an example of -- I think it is Word Press.  It has a save function.  Auto saves.  And it auto saves.  And it auto saves.  So you are constantly seeing the save drafts and then the second you stop typing the cloud icon toggles.  It is moving so I can't stop it.  There's a flashing animation of the auto saving.  It says saving and then flashes and says saved.  It does it over and over and over.  A user has no way to stop that animation.  Tweet on the screen says I'm so glad you can hide media preview on Twitter iOS app.  As a person showing ADHD symptoms, it is a lot less distracting.  Twitter has it, Pinterest has it, and giving them that option to not have auto play.  For settings this is the recommendation slide.  This is a big one.  Use logic.  Sometimes stopping animation is good.  Other times simple things like turning off auto play is giving you the setting to do that outside of the preferred motion on the computer level on your site like Twitter or Instagram -- not Instagram, like Pinterest.  In the reduced motion sense fading is so much less intrusive than sliding in.  Things like being able to turn off animation on hover is really important.  Limit the user required dismissal of animations.  Those better be tied to the cuff.  Allow ad blockers.  We have to stop.  We're in a war right now between how annoying can we make our ads and how much people will download ad blockers.  It is just spinning.  Let me run through my last couple of conclusion slides.  Listen to, hire, and ask disabled people.  Shouldn't be hard.  But it is really is these day.  Nothing about us without us.  Nothing should be done without asking and bringing people in and paying them for their time.  Ability is a sliding scale.  Design with that in mind.  What bugs them and bothers them at 10 could like me bothers them Google did a thing and I couldn't e-mail anybody.  Ability changes.  Microadepressions exist on the web and they tell disabled users they are not welcome.  Takeaway number four, standards are never going to be enough.  They are just the start.  Let's take the standards that we have apply them where we can and push them further.  Second to last microinteractions and animations add a lot of accessibility for cognitive disabilities.  We're talking about pairing things, complex interactions, pushing buttons and getting that live feedback right there knowing what I did worked.  Those kinds of interactions have a lot of plus for cognitive disabilities.  On the flip side the microinteractions if abused can create barriers with users of cognitive disables.  I have one more slide.  Surprise.  Number seven.  Give your users settings.  Give them settings.  They know what they need better than anybody else.  Give them the ability to decide how they want to have receive notifications.  If they have toast, they don't want to see that right now.  They toggle that off.  Their badge still updates.  Imagine if Twitter hit you with a toast notification every time.  How overwhelming.  That's it for me.  That's it for me.  Thank you for your time.  I'm a little over.  Thank you for your time.  Thank you.

>> Thank you so much.  You did great.  We've got eight or so minutes left to take some questions.  Let's jump into that.

>> Yeah.  Sure.

>> Thanks for everybody that's been participating and submitting questions and uploading them, et cetera.  We'll get right to it.  Here's one that says what advice would you give to someone with the cognitive disability when they feel invalidated bit fact that people don't perceive their differences or don't believe them because they use all of the spoons putting up a socially acceptable front?

>> Masking is exhausting.  I feel this person.  It is tough.  Empathy -- the hardest part about being in the marginalized community is unfortunately because of the systems that's been built around us based off of racism and sexism and ableism, we are forced to be the teachers.

It is not our job to teach people to be inclusive.  Unfortunately that is where we get pigeon holed into.

>> More spoons.

>> Yeah.  More spoons basically.  What my recommendation would be is lean on the disability community.  On Twitter -- I don't know if they are a Twitter user.  There's a fantastic, robust, brilliant disability community that has resources and articles that explain.  Black girl lost keys has a fantastic blog.  It talks about how difficult it is.  Things like rejection dysphoria can be enough to end your day.  See what they have to save spoons.

>> Great.  Thanks, Shell.  Here's one that I was reading through earlier.  I think it is about session timeouts.  Do you have any strategies for conveying countdown it is or eminent timeouts that don't hijack a users focus or create unnecessary stress assuming there's some security requirement that requires the app to that have type of timeout?

>> Yeah.  I'm so against timers.  I hate them so much.  I have on my screen right now the time and I have the seconds hidden.  There are very few instances where users are going to benefit from seconds.  Ordinariered tickets and stock prices.  Those things change rapidly.  When we're talking about timeouts giving if the user the warning and you have five minutes rather than four minutes.  A giant ass timer on the screen.  Just do away with seconds.  You've increased the accessment for cognitive a ton.

>> Don't introduce anxiety.  I'm going to break my uploading rule.  This just crept in.  Do you have any recommendations for who to follow on Twitter to learn more about cognitive disabilities?  Aside from this one right here at the bottom of our screen.

>> I typically have a ton of people to recommend.

>> You haven't submitted your slides yet.

>> I'm going to tweet out a list.

>> That was anonymous.  Start by following Shell.  Sometimes I completely miss important conveyed by the microinteractions.

It is called bright girl blindness.  It is eye tracking software.  Users don't see them anymore, because we've learned to block them out.  Same with carousels.  Time and time again nobody interactions and nobody cares about carousels.

>> It is a bunch of people fighting.

>> Different spaces.  All I'm saying is there's research out there that shows people don't look at those.  I think that is a conversation that they don't want to have anyway.  Inviting them to realize that there are users who want -- who don't mind ads and have to block them because they move.  It is a downward spiral.  The ads get more aggressive and they get even more ad blockers and they get more aggressive.  There's a lot of great resources.  Niemann Marcus to look into the spiral and know the non-moving ads are more likely because people aren't block them.

>> Interesting.  Unfortunately we're at time.  Thank you, everybody, so much.  Thank you, Shell.  Again the slides will be made available.  I suggest everybody follow Shell on Twitter.  She tweets a lot of cool stuff.  You promised that list of people to follow.

>> I wrote it down.  Thank you so much for attending.  I appreciate your time and attention.  I hope everybody has a great rest of the day.  I'll let you continue the signout.

>> That's all.  The AV guys will tell us when we can go off air.

>> All right.

Type: Breakout

Track: Wildcard

Accessibility is best implemented when it is desired and not enforced. It should be considered in everything we do like a spell checker so that it is not an afterthought but is baked into every single project stage from start to finish. Leveraging existing tools and taking simple steps can instantly increase your organization’s accessibility and help build towards a more sustainable, accessible culture within the organization. Join this session to learn how Aditya and his team of 40+ advocates are building an accessibility culture within a division of more than a thousand employees that anyone can easily adopt to drive a culture shift in their organization.

 

 

>> Welcome everyone.

If you're looking for the forming and enterprise accessibility training program you are in the right room.

We will get started in a couple of minutes.

Welcome everyone of you just joining us, we will get started with the next session here in just a few minutes.

We are on time for the session which is always good.

Welcome everybody if you are just joining us.

Thanks for bearing with us.

Rule is more people trickle in so they can get all the information.

One more minute and we will get going.

Welcome everybody if you are just joining.

Hi everyone, if you're just joining us now my name is Liz.

I'm from the DQ team will be moderating today's session which is swarming enterprise accessibility training program brought to you by Rob O'Connell.

Thank you Rob for joining us.

I will take care of a little bit of housekeeping before we get going.

First off, just a reminder that this session is being recorded and will be available on demand for all registrants.

Second, we should have accessible slides for the session if you scroll down to the bottom of the session page under the documentation section.

If you require live captioning there should be streaming right below the video stream.

Lastly, we will save about 10 minutes for questions for Rob.

And any questions you have for him to the Q&A section which is to the right of your video stream.

We will get to as many of those questions as we can at the end.

With that I will go ahead and turned over to you Rob get started.

>> ROB O'CONNELL: Thank you very much Liz.

Hello everyone.

I know you are in different time zones around the world so I won't attempt to say according to your time of day.

I will say warm wishes from taxes.

We have been through a significant snowstorm.

We got through that okay.

Now we are probably heading toward warmer weather which is welcome for me since I enjoy gardening when I am not at work.

I'm a senior designer and accessibility advisor at USAA.

I've enjoyed working there since 2007 as a UI designer and almost immediately saw there was a gap in our understanding about what it takes to make a digital interface accessible.

I voluntarily became the subject matter expert for accessibility for all of USAA and remained in that role for about the first six years of my time there.

Subsequent to that we developed into accessibility operations group and added more people and more roles.

I continue to serve with an interest in universal design but mainly concerned with the materials.

I have stayed in that role because of my passion for interface design and accessibility.

Without further ado I will kick into our subject for today which is swarming enterprise accessibility training program.

What I will present in the slides I'm hoping is something of a manifesto.

For those of you who may already be on your journey or may just be beginning your journey within an enterprise organization and still need some guidelines for waypoints by which to mark your journey.

What I offer are not really a ordered steps but rather a milestone that you can look at.

Some of the and you end up revisiting as a training program grows and encompasses more rules and reaches more of the enterprise endeavors.

We begin with the first milestone which is to sculpt the accessibility training landscape.

For that we need definitions.

I will try to define accessibility and what a program is around accessibility and what it means to be enterprise in that context.

Our first definition pertains to accessibility training itself.

As I mentioned, when I was in my first six years I did a lot of the training myself.

I had two exposures working for states on opposite coasts of the United States of America.

In both cases they are operating with accessibility guidelines.

USAA had a lot of learning to do when I first began my time with them.

I did not come up with this definition at that time, and after some reflection I have come to the realization that all accessibility training is the transfer of awareness, whether that's disability awareness, the knowledge pertaining to what it takes to make an interface usable or inexperienced usable.

And the skills which is the know how, things you need to know in order to make things or do things.

We wanted to be able to transfer what awareness we had, there were areas in which we needed to still grow but wanted to transfer that knowledge and skills to any training whose role in the company or in life or business would be to carry that knowledge into their skill set and be able to serve the needs of people with disabilities.

Whether you were creating content online or engaging people in a service oriented role we wanted you to be able to have the awareness, knowledge and skills needed to do that.

And to carry this understanding of what accessibility training is, a transfer of knowledge, skills and awareness is into a program status it would require a significant amount of rigor.

We took that same definition of accessibility training and broaden it into a more rigorous plan where we could monitor it and measure by it.

It would have to become industrialized in order to fit our needs.

I do find it in this way.

And accessibility training program is a standardized and curated side of accessibility training guidelines, materials and methods that is regularly refreshed and transferred to trainees.

Whose awareness, knowledge and skills for serving the needs of people with disabilities is by that side of accessibility training guidelines and materials regularly measured.

It puts a container around accessibility training and turns it into a program that you constantly monitor and measure.

That way you are constantly improving it into something that subject to compliance, rules and regulations which makes it industrialized and ready for distribution.

What makes an accessibility training program enterprise level, for this I thought about it a little bit.

It's something that sort of needed to be large-scale it needed to be intrinsic to the nature of the company.

It couldn't be something that was a package sitting in one region of the company.

For that purpose I said these are the characteristics of an enterprise program.

It needs to be systemic.

Meaning, is distributed among lines of business, locations and time zones companywide.

So that the skill set and toolset and mindset of the company was ubiquitously aware and ready to embark on the knowledge that was necessary to do the business that company is in.

In our case it's financial services at USAA.

Something that is systemic is infused into the company.

Something that is scalable than would be broad ranging.

It had to be capable of reaching a vast number of employees who work in diverse and specialized customer provisioning roles.

Not only did it need to be broad ranging, but it also needed to be varied and peculiar.

That's what I mean by extensible.

It means that it could be adopted to the specialized knowledge areas and practices of each role.

We ended up defining at least as a working foundation several roles that we thought we could train to and focus our training objectives around them.

That was the general employee, that's the all rules and common for awareness training and some level of training around knowledge.

But very high level.

Driving into more specialized rules, we knew that copywriters would need some exposure, certainly UI designers and developers, very specialized interest in designing accessible interfaces and engaging our members and the public.

As real as the testers who would basically act as the user during the process of testing those interfaces for usability including testing with screen readers in zoom magnification and other forms of interaction.

It also extended to marketing and our customer service reps as well.

These are very different media spaces.

Marketing especially since radio and print media in large-scale as well as video production.

All of those have a learning curve when it comes to accessibility.

They are very different roles and to that extent to be extensible means you've got to be able to adopt to the peculiarities of those roles in ways that don't become redundant with the general employee training.

The second milestone in this journey, you don't have to visit these in order.

They are points on the journey or a map to the space of accessibility.

They are waypoints you may have to come back to again and again.

One of them is to assess the enterprise problem space.

The enterprise level of training, they are essentially two big problems that I was trying to get my head around early on.

It took some years.

I did not do any of this alone.

I have some great colleagues who are highly skilled in both managing and production and other skills they bring to the table.

For which USAA can be very grateful because my skill set was fairly limited to just interface design accessibility.

One of those enterprise problems we had to overcome with regard to a training program was the inability of accessibility experts to train across all other expert knowledge disciplines.

The difficulty here is it's just a big knowledge gap.

For example, I know very little about the service industry.

We have MSR's, member service representatives and they are essentially the customer service representatives to manage calls and complaints and handle requests over the phone.

Sometimes on shot.

That is a service area that requires a certain degree of expertise.

In order for us to overcome the accessibility barrier there, require some level of awareness of what it takes to be a member service representative.

Those are things that not every accessibility expert has in large numbers.

That was one of the gaps, the knowledge gap.

The other was what I would like to call the availability gap.

The inability of a small number of accessibility experts to scale training to a wide range of training situations and schedules.

I'm not speaking here about the availability of training materials.

If you have a learning management system that can always be available.

I'm speaking here specifically with respect to providing training in a variety of situations in all the ways in which training can be provided, whether it be live sessions or PowerPoint slide or experiential things.

Or even in the case of service representatives to do scenario-based training with people.

There aren't enough of us be available not only online and on zoom, but even in situations where you have to do real-world life training.

It was going to have to go beyond us is essentially what I'm saying all of this.

We're going to have to enlist help from other lines of business and other rules within the company to advocate within their own areas with Eric sibility training was.

I have silos of business and the special knowledge in each of those areas.

We had engaged them all.

Course, we could invite people to come out of the stores and meet in the lobby with us and that was the approach we took.

Rather than having to engage each one individually.

That made it a little bit easier, at least the concept of being able to do that.

There will several essentials we thought would have to be part of an enterprise training program.

For example, the training materials themselves would have to be compliant with accessibility and law and industry standards.

That is a must-have for the materials themselves.

The development of it would have to be inclusive of trainees by abilities, roles, mines of business and so forth.

Learning objectives would have to be role specific for each customer facing experience and service reps.

Front lines to create content for members who touch the interface and touch the glass so to speak.

As well as people who are engaging face-to-face.

Training would have to have a review cadence that was recurrent in order for it to be truly enterprise and robust and measurable.

We would have to make sure that training was part of a scheduled process of exposure, whether at the moment of higher on a regular basis recurring.

Training deployment would also have to be comprehensive, meaning you would have to reach every employee in that role.

Whether they be true employees are higher contractors who are essentially acting as employees in that situation.

It would have to be monitored for training attendance and the success of the training through assessment and testing.

Finally, we have to be curated.

The body of material used for training as well as the test results would have to be curated so that we could manage that.

That of course would have to be done centrally, but we need the call for action and cooperation for all to handle that training.

Our third milestone was to segment this enterprise problem.

For that, we were going to need some help.

In fact, there had to be some background.

This was one of the missing ingredients that I learned early on.

For six years was like swimming upstream, trying to convince the enterprise of the importance of accessibility.

We got a lot of standard responses of why this is important.

It only touches a few people.

Why am I responsible for this?

That pushback initially.

We don't get that anymore.

The reason we don't is we now have a companywide accessibility policy.

Putting the policy in place, watch the dominoes fall.

Once you have executive endorsement at a corporate level and it aligns to the Americans with disabilities act but nondiscrimination, everything then flows from that.

It has made a profound difference in the mindset of all lines of business in every level of management.

From the policy which is essentially a commitment to make sure everything was accessible from the standpoint of a public and member experience we also then drew out several standards.

These standards touched on various specific areas.

Whether they be physical facilities, the ICT procurement, we are still working on that.

We broach that.

Now we are in a conversation with people and procurement to make sure employees are getting what they need.

Experiences that are public facing are also provided with equipment that meets those standards.

Customer service interactions are now governed by all knowledge base of procedures that accommodate to the needs of people with disabilities and follow ADA standards.

We have standards for third parties that were just engaging with now.

We are developing that fully.

As well as complaint management.

That standard has been in place for some years now .

How to manage complaints in a timely way to make sure people with disabilities get the accommodation requests they need.

Last, but not least because this is where we began, we want to make sure that all of our digital content aligns to standards.

We have our own USA standards for digital accessibility that align to the WC AG would also supplement them in some ways in a centralized repository.

None of this is training per se.

It sets the background for it in ways that are quite impactful.

Having this infrastructure in place means we can then begin to build on the requirements we have created for facilities and the requirements we have created for digital documentation and marketing and begin to train to those standards.

For that to take place we need to form an enterprise training governance platform.

The very first thing, was the legal layer of the repository of requirements.

It just so happened that our legal counsel was able to give us a number of guidelines, high level business requirements that they developed from existing federal regulations as well as case law.

There is no statute or mandate that says a company must train on the subject of accessibility.

Almost all of the legal precedents are based on execution of the skills that lead to accessible websites or inaccessible service experience.

To that end, we really needed help from legal to create high-level business requirements out of those case laws and regulations so that we would have something that we could work from that would have the authority of the law but be within the company.

It would be more on the compliance level rather than on the regulatory level.

We ended up with nine of these.

I cannot show you what they are because of attorney-client privilege.

I have created at least a mock version of what a business requirement would be.

It would have a high level description of what the directive is which would order a specific training action.

And it's action agent who would be responsible for it whether it's an affiliate, third-party or an employee or somebody in the service role.

We would set the scope very clearly then as to the subject and audience of the directive and any impacts that it would have.

The application and lines of business.

We just wanted to make sure that we were specific enough that we can turn this into world-based training and aligned to these high-level business requirements when we build our training modules.

One of the first things you have to do as you are creating this enterprise program is identify your company's frontline roles.

We began with a set of rules, is not as far-reaching at as I think it's going to be.

We decided that anybody that was creating content that a member had to engage in directly or was creating a service experience that had a direct face-to-face conversational exposure was going to be a role we wanted to train two.

These roles would be content providers and service reps as well.

People who would engage other people who have disabilities we need to engage in directly or indirectly with the published content they create.

These roles, the frontline roles of the highest accessibility risk to any company.

These are the rules we wanted to train to first.

In a distributed Corporation frontline trainees may be under separate managers from the accessibility governance group.

That is certainly the case in a big company like USAA.

We have affiliate organizations as well as many sideload lines of business.

They each interestingly to some extent already created their own accessibility training materials.

Sometimes they would gain from the general accessibility awareness training that our group provided for the whole company.

They also had specialized needs within their own lines of business and began to ask questions and move on their own.

In some cases, they would be using third-party accessibility training materials.

We did not discourage that, in fact we welcome it.

What it did entail is if you want to have a program we are going to have to have some way to measure the success of that material.

Because there was no way for us to control all of the ins and outs of what material they were using.

We had to add least assess it, measure it against her own learning objectives and then supplemented where we felt we had learning objectives that needed to be addressed that were not being addressed by the materials they were using.

Prioritize your training roles.

You may need to start small.

We started with people who are engaging digital interface experience as well as member service roles.

These are our roles as well as the top level, every employee at USAA had at least some exposure to general accessibility and awareness training.

That was the common rules.

Then the designers of course, they are the ones who are engaged in the user experience.

Developers, are more focused on the system and robustness of serving many platforms.

Testers who would act as advocates and voice of the member invoice of the public to ensure that everything was following WC AG standards.

Finally, the member service representatives.

It was an interesting experience.

I had an opportunity to engage our service representatives in some training.

I learned an awful lot from them, probably more than they learned from me.

It was great to be able to get them to enlist them as the experts in their area and to expose them to what accessibility standards there were.

Some of them were already fully engaged because he had a complaint process that was managed by another member of my team.

She had done an outstanding job of engaging in that training area.

There was still not a regular, vetted and controlled system of learning objectives until we got together with one another and began to form them.

In order to form some learning objectives around your training, you will need to enlist your company's frontline roles.

You have to enlist trainers from various lines of business.

If you think of it, these are like horizontal cilos within any company.

They have specialized roles within each of those silos that we know nothing about.

Without a doubt, when they are large enough, like our corporation is they have their own trainers.

They train to the subject of their expertise.

One of the things we found helpful was to engage those people who are actually doing that training, in some cases it will be people who are specialized trainers, professional trainers in the subject areas for which they have been hired.

In other cases it will be those leads you are specialized in some skill set for which they are the key person to train other members of their team.

The key was to connect with them, with those business experience owners in each line of business and to ensure whenever they do their training that they incorporate accessibility into those modules of training.

We had to explain her training program in collaboration was a centralized accessibility governance is key to fulfilling corporate compliance with regard to our policies, standards and requirements.

And to homogenize that experience.

We did that, we've done it with all the rules that are designer developer in each of those is in a guild.

If you think of the role specializations are like the horizontal bridge.

Many of those roles, designer roles will be across the various lines of business.

You have the vertical silos the lines of business in the horizontal rules and skills that they train to across the range of the company.

Somewhere in that grid is the specialized needs of each line of business with specialized skills and some case of each role within that line of business.

We began to invite role specific trainer delegates to an annual accessibility training Summit.

We began our first one about two -three years ago.

We were able to engage our digital content creators in that summit.

We actually called it Denali.

We've had Denali one and two and will do three this year.

It's a high mountain in the United States in Alaska.

We were also able to create another similar summit for service representatives.

They were so different in kind and the problems they deal with are so different in kind from the kind of digital content creators deal with that we thought it was important for them to have their own summit.

We call that Saint Elias which is the second highest mountain in the United States.

That was something we are able to do.

We were also fortunate to have members of our team, some of whom have disabilities themselves.

It's always important -we made this even if they're not part of our team we engage people who have disabilities to come and speak to the needs they experience.

The exposure not only through formal training but even through user groups that we have on our campus from time to time has been greatly influential in changing the tide of the way USAA thinks about accessibility and its responsibility in that regard.

Milestone five, form accessibility learning objectives.

What this is and the program of training, this is like the no Child left behind set of standards.

It was a federal set of standards for all education levels for the primary grade levels of students in the United States.

By setting a standard threshold for each grade level and subject in the grade level, no Child left behind policy was able to standardize the methods by which we would measure the learning of students in America.

I took that practice as something of a model for how we build an enterprise training program.

What it entailed was we were going to have to create learning objectives and we would have to do it in collaboration with those who training each role.

That meant that frontline trainers would have to understand the work of fun client content and service providers and would have to contribute some of these learning objectives.

From our general common role training, it's the first of .

For each one of these learning objectives, we were going to have associated tasks that a trainer would do that list corporate cases, the measurable outcomes, things we should test for as a result of training session.

After training we can ask a test question and give an example of a site or multiple-choice answers.

This is standard learning pedagogy approach.

We measure the success of training by asking questions.

What we found is that we had to create as many learning objectives for each competency or role as were needed by that role in order to mitigate the risk of training and competence.

We simply did not want people out there who were not able to create great, user experiences that meet the needs of people with disabilities.

We did not want that to happen.

We thought, what do we need to train too?

What is that minimal threshold of learning objectives?

We created associated training pass for each objective and we finally created measurable outcomes for each of them.

For the common core we had some 26 objectives that we wanted everyone in the company to now.

We created a general accessibility and awareness training around that.

It's now part of compliance training.

It's required annually and we have to revisit and assess it.

Each of those had a special set of learning objectives in its own space.

In order to avoid the problem of redundancy we created an aggregate specialization.

The training learning objectives we had for all roles and common wouldn't become unduly redundant and repeated.

For those designer should take the 24 learning objectives in their specialized area.

What I've created is a diagram for ellipses and at the top of the diagram has one focal point of… Governing the 26 learning objectives for the common role.

Each of those ellipses branch out and fan out in different directions to cover the 24 learning objectives for UI designer, 24 front and developer learning objectives, 13 accessibility test or learning objectives and 13 service rep learning objectives.

A total 100.

Next year it might be a 101.

It's a way of ensuring that we were training a way that meets the needs without being unduly redundant.

Milestone six is to form accessibility training curriculum for each of the specialized roles.

That would mean that accompanying the learning objectives would have to be an outline that structure is what it is about those learning objectives that need to be taught and in what context and what materials could be used?

A curriculum in a formal sense is a template.

It's not the syllabus, it's not actual course material, but it is a structure of those things that need to be taught.

It presents it in an organized way so that it can be used as the basis for creating actual training.

I have looked at other curriculum models and it came to the conclusion that we needed a list of intended outcomes.

Those are the learning objectives.

A summary of a training goal.

Training needs, training needs and they are varied.

Almost all of our trainees are employees so this was an employee phasing experience to equip our employees to meet the needs of people outside of our company and our members in public.

I had to summarize available training resources, we had quite a few resources within the company but it was important for certain specialized roles that there were certain training materials and media available to them that might not be available to other groups.

We wanted to know what those were and to make use of those within those areas.

The key thing to remember in all of this as you create a structured curriculum for each role is that a curriculum should be result oriented.

It's all about the outcomes and ensuring you have your success measures measured for the things you have trained to do and that you do get some sense of progress over time as you measure it from year to year.

Let's begin with the training goal.

For each role that is designed or developer MSR and even the general common training, you want to have a statement of that role.

For the common area for example, this is the one goal that governs all of the training in the area for all roles in common.

Every employee has awareness of the range of human disabilities and of provisions that need to be made for all products and services to be accessible.

That is the overall governing principle by which we train.

We have to refine it over time in light of more insights, we can do that.

You're focused in on that one role, even the generalized role is a specialized role when you think about it.

What can you train too that applies to everyone?

Really have to think about what are those things that everyone has in common?

It applies also to other specialized roles.

Wanted to make sure we understood training needs.

These are general.

They may lack exposure to disabilities or accessibility design needs.

They will need new information on what accessibility provision is and what a disability is.

Some trainees lack any connection to people with disabilities.

At first it may seem irrelevant to them, but I think bringing people into the training Disabilities suddenly makes that vary relevant and has been a seachange at USA since we began doing that.

Some trainees may have difficulty adjusting the settings of the learning materials themselves, whether it be video-based training or computer-based training.

You want to make sure the training materials that we provide and the methods we use are themselves accessible.

It's always important, especially when doing life training retraining of resume to ask in advance of your trainees if they have any special accommodation needs.

You may need to provide finding which interpretation for example to some employees.

Those kinds of accommodations and becoming aware of those is an important aspect of the training.

The range of training needs.

Some trainees may require assistive technologies and adaptive strategies.

Many of them already have these within their workspace.

Many of us at USAA have been working from home for the last year because of COVID, we may need those specialized tools and provisions in our home space as well.

Just being aware of those specialized needs and articulating them in your curriculum is very important.

Some available training resources, we have LMS training, computer-based training, video-based training, power points and the like.

You will have your own specialized mechanisms and it's important that you at least articulate those and know what's in your inventory and be able to leverage those when you think it's the most appropriate way to present information.

You have your learning objectives all gathered together, you have to sort them and categorize them by their various types.

Some will be related to legal and regulatory even for a specialized role like developer.

There are some legal and regulatory things they need to know.

Some business requirements and operational related accessibility rules they need to know.

He organized that material for them in the curriculum and presented in a way other trainers can then within those specialized lines of business appropriate and build into their training materials.

To become fully enterprise you've got to inspector training resources.

We spent the last year going over those training materials that we reuse within specialized areas.

There were design specialization trainings and also some specialized training.

We actually made use of the University materials in some cases.

It wasn't necessarily required training, but it was training that we recommended.

We vetted those materials against our own learning objectives.

Did we find gaps?

Yes, sometimes we found things in the DQ University materials that we liked and we actually added them to our learning objectives.

In other cases learning objectives at the DQ materials did not quite in the specialized way USAA wants to train.

We had to create gaps in what her plan was to supplement that material through creating our own training resources that can supplement the materials we get from third parties.

Whatever third-party training materials you use we want to manage those accessibility training standards in such a way that you got some kind of regular authoritative body that can look at those materials and get a report on where was the alignment?

Where were the gaps?

Are you remediating those gaps on a recurring basis?

And provide a record report of the approvals that were made.

Caller group degrades.

The group for review of the price training standards.

We had to create a charter with the rules and responsibility for that group.

And a member roster.

Some were from her own team of accessibility experts.

In many cases these are people and lines of business whose role was able to have a rule that there was accessibility learning curriculum and to be promoters of the survey would participate with us and at the same time be able to promote that knowledge in the company.

We have to convene at least once per year in USAA.

It might be important to convene more often should there be changes in the regulatory environment or new high-level business requirements from legal.

It's important for everybody to be aware of what changes and when so that we can be timely in our distribution.

Having delegates in various lines of business will help us to monitor and assess the training materials and schedules.

In every specialized line of business, whether it be banking or life insurance in our company or the various lines of business you may have in your company, you want to make sure that you are mitigating risk on a recurring basis and that you are assessing and monitoring the training that goes with those risks that tries to reduce the risk for the company.

Need to create an inspection process and regularly review the training requirements and guidelines for currency and relevance.

Would be important for me to have at least some event that has to take place on a regular basis in evidence that that event took place, whether meeting minutes to say you approved the following changes or some kind of an assessment.

It may be a test that gets run own training materials.

Something that proves the inspection took place.

That would be a control for the inspection process.

And then require regular reporting of those inspections to make sure training materials that are being used are current and reused on a recurring basis and we are measuring against the success of the training by looking at test results on average.

Making sure that everybody who is in a particular rule is getting trained on a regular basis.

If people are skipping training, that something that their manager needs to know about.

This kind of rigor over the training program then turns this program into something that is truly enterprise-level.

Wherever there are gaps discovered, either training materials for rollout and deployment of the training we want to remediate those as quickly as possible to get that done.

The last milestone is to nurture the accessibility training discipline.

This is something we do by hosting regular training summits.

We convene excessively trainers to refresh and reinvigorate them.

The beautiful thing about this is it's an exclusive event.

It's an exclusive inclusive event.

We like the idea of that.

We want to limit attendance to the training leads and delegates among whom should be people with disabilities so that it becomes an enriching experience for everyone.

Collaborate with participants to set the agenda.

You can achieve anything you imagine in life but you can't do it alone.

You want to list training needs and delegates from each of the lines of business and get them to add accessibility to their arsenal and be the champions within that region for training.

In encourage group interactive experiences.

It depends on what you have available for your breakout sessions during the summit.

Usually it's either whole or half day summit.

You can use Fox notes or murals to unleash creativity.

Focus on achievable outcomes.

Our first summit, we actually created learning objectives.

We did not have them all done yet, but at the end of that session we had created a number of learning objectives in each specialized role of those who had been invited to the meeting.

You want to accomplish moving that will marker down the field in the course of your summits.

This is my last slide, make sure you make heroes out of all the people who help and support in the training role.

Meet throughout the year at least once per quarter to stay fresh and engaged.

Encourage newcomers to take on new challenges.

Don't be afraid to give somebody a new delegate responsibly.

People like that.

Rich veterans with new roles and responsibilities so they don't get stale.

Share knowledge among the disciplines.

Avoid a single point of failure expertise.

It's great to have people who are knowledgeable, but you have got to shadow those experiences so that you have more than one person with the expertise.

Elevator compliments of groups and individuals.

This is eight people thing.

Limit the proud, lift the humble and above all love one another.

That is all I have for today.

I'm willing to take some questions and answers.

>> Thank you so much Rob, that was great.

We do have some questions here.

We have a couple of minutes I will dive right in.

This one, any advice for a small team of designers and developers currently learning accessibility are in charge of training on accessibility to all of their development teams and PMs and getting everybody on board in a big company?

They don't have time to sign for it or budget to do it.

Or any good resources to use.

>> ROB O'CONNELL: The nice thing about PowerPoint or the like is that it's fairly cheap.

The only thing you have to do is create content.

That is how I began.

I had a set of training materials I would reuse and I would invite large groups of people to take the training.

It was live and in person at first.

We did not use Skype resume too heavily then.

Music quite a bit now because our company is very distributed, much more so than when I began.

It is easy and cheap to create that kind of training material.

That is a good way to start.

Course, you're not delving into anything other than what you already know at that point.

To do the kinds of things we have done to go into the specialized areas that we don't have a lot of experience with this require enlisting the help of others.

Can do that with training materials you provide and have others participate with you and those zoom training experiences.

If you don't have a high budget and you can't afford the deque training modules there's plenty of material that's free and available if you want to make use of it.

You have to bet it because it's not going to meet all of your needs.

Does not absolve your responsibility from creating your own learning objectives.

Need to have a set of standards you say this is us.

This is what we trained to paste on each role within your company.

>> I think we can squeeze one more question in here.

How did you get leadership buy-in for this training program both in C suite and team and departmental supervisors?

>> ROB O'CONNELL: I have been doing it for years.

I have been known as an accessibility expert since 2007.

It is also delegated this role.

It was something that I loved to do and fortunately for me my director said you were going to be doing this.

The buy-in really comes as a reflex of the fact that we have an accessibility policy.

Once we got that policy and standards in place, those were not specifically about training.

They were about the outcome of training and making sure we were aligned with ADA standards.

Once we have those in place it was not a far distance.

Just recently, painting the high-level business requirements from illegal as well gives us even more impetus within the company.

Now it is a compliance -related issue and it's going to drive out.

Having those points of leverage is critical.

All you have to do is drop the weight of accessibility training on one end of the lever and watch the Big Stone role.

That is essentially what happens.

>> Thank you so much Rob for a great session.

Thank you to everybody who joined.

We still have a handful of sessions left.

I hope you guys enjoy the rest of Axe-Con.

Thanks again everyone.

Appreciate it.

>> ROB O'CONNELL: Thank you for attending everyone.

[end of session] 

Type: Breakout

Track: Design

This session explains the processes and artifacts required to integrate Accessibility into the Practice of Design. I will explain the difference between accessible design and inclusive design, and give practical guidance for integrating accessibility into Design Research, Visual Design, Interaction Design and Content Design.

 

[missed start for coctail class]

 

graphs.  And descriptive it text for images.  If the text is meant to be read, don't put it in the image.  Ensure sematicly meaningful page structure by using paragraphs appropriately.  Which brings me to visual design.  Visual design plays a significant role in communicating a brands proper position and personality.  Remember the address from five or six years ago?  You know, the one.  Was it blue and black or was it white and gold?  It caused quite the uproar on social media.  This little color illusion reminded us all that color is almost never seen as it really is.  We all see colors slightly differently.  And our perception is literally comelied by the context in which we view it.  Such as the devices screen and the surrounding environment.  You might have a shadow or something off of your wall or window.  Visual designers, don't use color alone to convey meaning.  Always test your designs with a color contrast analyzer tool.

The simplest place to start is to design in greyscale.  As this forces you to consider layout, typography, and visual balance before tackling the subjective of color.  The design should be clear and easy to read with a thought through text hierarchy.  By going in greykale it forces you to not use color alone to convey the meaning.  As you add color to your design, remember that color is an -- exact and relative art form.  Being an exact, we need to select colors that will perform well within a range of environments.  This should not be under estimated as roughly 8% of men and 0.5% of women worldwide are living with some sort of color blindness.  Your choice of colors will depend on the look and feel of your brands visual identity.  This is time for experimentation.  You'll want to use a color contrast analyzer tool to help you get at the look and feel that you want.  Ultimately visual design is about creating delight for all of your users.  And my friend, Rich Donovan said it best.  Customer and employee delight is the goal.  All day.  Every day.  Understanding and delivering actions that delight define whether or not revenue is maximized.  Diverse demand has changed how great brands deliver delight.  Are you ready to unleash different?  I don't know about you.  But I'm more than ready to unleash different.  We have a very real opportunity right now to build back better.  And I'm hopeful that will.  Not too long ago I asked a form every colleague what he thought the role of visual designers were in non-visual interfaces.  He couldn't really give me a good answer.  My answer was there.  As the role of visual -- it is the role of visual design to create delight.  Visual designers have a very important role to play for non-visual interfaces.  Because it is their job to understand what a desirable, pleasurable, and delightful experience really feels like.  It is really easy to say an icon or the image is just decorative.  It is much harder to take a step back and ask yourself why did I choose that particular icon or image.  Is there something I want my users to get from it.  I hope you keep this in mind the next time you and your team are deciding what the alt text should be on the image or icon.

I know I've covered a lot today.  I hope some of this helps you in your journey of making this world a better and more inclusive place for everyone.  Thank you.

>> Thanks, Alicia.  That was fantastic.  We have a number of questions coming from the audience right now.  I'm going to start firing them off.

>> All right.

>> One of the questions are where can we see more of how to best annotate with accessibility?

>> So a resource that I found and I particularly line is accessibility blue lines.  It was shown in my slide.  I think what you have to find of realize about annotating for accessibility is that the way that you annotate is going to depend on the needs of your team.  Because like I said, you don't want to annotate everything.  You don't want to annotate things that you don't have to either.  So it really is a thing to have a conversation with your team with.

>> Awesome.  From Mark he has a question.  Do you have a favorite source for inclusive language?

>> That's a really good one.  There's some inclusive language guides out there.  I don't have a favorite.  Please share your favorites with me on social media.  Because I mean there are some out there.  I don't think -- I think that's where we can improve as an industry.

>> So we have a question that says you to not use gender and race in descriptive text.  Why would we only allow those details to those who are sight-enaged.  Why wouldn't we provide those details to sight-enabled.

>> I didn't say for non-sighted or sight-enabled.  It is in general you shouldn't use those descriptors unless it is relevant to the story.  Because you really don't know someone's preferences and the way they choose to identify themselves.  So if you -- if it is not needed for the story, leave those out.

>> Got it.  Thank you.

And what are the different strategies that you recommend for inclusive design?

>> So I think basically have a curious mindset is the number one strategy is always ask why.  Ask the five whys.  And really take a learning -- a learners mentality to design.  You know, we're all learning to be better designers.  I would say that's the best strategy for inclusion.

>> And that one -- there's another question that kind of relates to this.  How do we go about the research that you were referring to?

>> Okay.  So when you are doing your research activities it is really -- you really have to just get out there.  You have  to, you know, meet different people and use social media and networking to your advantage.  And access different people that you might not have talked to before.  There are certain services out there like fable tech that can help you recruit participants for your research for sure.  But really it is about just expanding your network and inviting different people into your research practice.

>> I have a question from another participant.  I work in the design agency.  We work with many different clients.  A common issue -- this just jumped -- a common issue I run into when running accessibility training is convincing clients to use inclusive language.  Do you have any tips for getting buy-in?

>> My main thing for getting buy-in is meeting them at Starbucks or the coffee shop and having a regular conversation with them.  I think bringing a positive personality to the conversation is key.  It is not just about always convincing people.  But it is just about meeting them where they are at and seeing if we can find some common ground.  Then intuitively moving from there.

>> That makes sense.  So I have a question for Vanessa.  I'm so confuse about whether or not to use the word click.  I've heard to use select.  I've also been told never use select unless it is for a list or something like that.  There doesn't seem to be on agreement on the button action word.  Click is universal and not ableist language.  What are your thoughts about that.

>> I actually prefer select.  Not everyone clicks.  When you use select it helps your QA folks write their test cases in a way they can run the same test case for over a multiple devices.  Select is a more inclusive tomorrow, because you can select on a mobile phone.  You can -- that could probably touch or could probably a keyboard or describe a switch control or another assistive device.  So it is not really specific.  So that way you can use whatever you are doing, your annotations and things for over multiple devices.

>> That makes sense.  So I have another participants note.  Awesome presentation.  How has computer access changed for you overtime.  Do you require non-mainstream tools to do all of the work that you like to do these days?

>> As a really good question.  The answer is no.  I don't require anything that's not non-mainstream anymore.  But when I was younger, I actually tried dragon naturally speaking back in the early 90's when you literally had to train your dragon and a silent room.  You can imagine how horrible the experience was as a child going through that.  Now we have voice technology in our homes; right?  With Siri and Alexa.  It has become mainstream.  It is not an assistive technology anymore to use your voice.

>> Can you give some examples on what are the dos and don'ts for inclusivety words?

>> Sure.  When in doubt always use person-first language.  I say that because you don't know how someone identifies.  For example, I don't really identify as a disabled woman.  I do identify as a woman with a disability.  So when in doubt always use person-first language.  And also when you are describing someone's disability, it is important to realize that assistive technology and wheelchairs are not things that are negative; right?  So you wouldn't say someone that was bound or confined to a wheelchair.  Because a wheelchair can actually be quite liberating.  Just be cognizant of how you are describing people and that it is always in a positive light.

>> Great.  Lastly, we have a question about what other resources do you recommend to learn more about the topic?

>> That's a great question.  So I mean there's a lot of resources out there.  The UX research collective has just done a conference that there was a lot of great speak percent.  I read a lot of books.  Seek those books out.  I mentioned a few in my talk.  Mismatch by Kat Holmes and also Rich Donovan's book "Unleash different."

Really I mean talk to different people.  Get a lot of different resources.  Expand your books and resources that you get today.

>> Thank you.  Any final comments to the team that we have here?

>> Just thank you.  I hope your evening is absolutely wonderful.  I hope you enjoyed my talk.  You can follow me on Twitter at Ali.Alicia or connect with me on LinkedIn.

>> Thank you so much for the great session.  And thank you to everyone who joined us.  Hope you enjoy the rest of Axe Con.

 

Team Approaches to Accessible and Inclusive Design: a Case study on the COVID Alert App and Healthcare Portal

Type: Breakout

Track: Design

Everybody has the potential to craft inclusive experiences when they talk to the people who operate & use services. This talk is a story of how a grassroots approach to accessibility and inclusion infiltrated the roles on Canadian Digital Service product teams allowed us to scale accessibility within rapid development of the Covid Alert exposure notification tracking app in just 45 days from start to launch.

 

We will talk about how organizations can prioritize accessibility and inclusive design and consider the points of intervention in the system to leverage better outcomes. We do this by exploring the space of possibilities and uncovering points of exclusion. We will explore the role and impact of service, interaction, and content design as well as their intersection with development, research, and product. Product is not linear. Design is not linear. Inclusion is a spiral of access points and off-ramps. Let’s go on a journey together and explore more inclusive service design and delivery.

 

[missed some of the start]

 

>> Thank you folks.  I would like to talk 

We are working in multi disciplinary team 

 

 

>> Screen froze.  

We had to start with the COVID alert app and trying to ensure we were 

making it accessible and inclusive from the start and had this launched 

in less than 45 days.  I am excited to dive in to behind the scenes and 

some of the key considerations to make it as accessible.  Government 

services should be simple for all.  That is what the mandate is, serving 

people better.  We do that through dedicated teams of people who are 

working towards the different levels of government to respond to needs.  

And so everybody has the potential to craft an inclusive 

experience.  When they talk to the people who operate and use the 

services, because at the end of the day we're all in some way, shape or 

form, an experienced designer whether the roles in which we're hiring 

for in the descriptions that come, how we staff and set up teams, the 

choices we make as an organization and structure all play key roles.  

So it is also important to know it is part of a system, so the 

main outcome was to help reduce the spread of COVID-19 by creating 

thoughtful privacy notification service that addressed as many barriers.  

As the pandemic started to roll out we got in to June and the government 

of Canada announced that it would create a nationwide exposure app.  So 

we got started with an open repository called COVID shield as well as 

apple Google frame work that was released on phones.  So I want to take 

a step back for one second and look at what is it that we're here to 

talk about.  Because there are a lot of considerations on what is 

exposure notifications, and it is not something around a year ago or 

five years ago.  Technology didn't exist being utilized in this way.  

There was a lot of concern about that, so I want to know what isn't 

COVID alert.  It is not contact tracing.  It is important to note that 

it values privacy and built with strong considerations and went through 

security iteration as part of its way of how we look at servicing 

people.  We needed to ensure that it was a reliable and consistent 

experience honest with people.  That is why it is also voluntary, so you 

can download, delete, disable Bluetooth which make it not work and gives 

people choices on what to do when they're using it.  So when we talk 

about moving in a quick manner to respond to public health crisis, 

launching something we haven't started before in less than 45 days is a 

big deal.  There are a lot of thing you may need to consider.  On the 

screen there are two pictures of the COVID alert app.  That is the first 

that allows you to select the language, where English and French are 

recognized.  And it is first screen once set up to let you know you're 

set.  

There are a lot of routes we can choose, different paths.  So we 

needed to pick some things that would guide how the service would work.  

It needed to work well, but also needed to be used by as many people as 

possible.  So that meant the service had to have some pillars that it 

would consider every step of the way and guide all the decisions.  

Essentially what happens here is that we needed a service that would 

detect and know if you had been around somebody with COVID-19 you would 

get a detection.  It needed to guide you what the next appropriate 

action was, what does the province ask you to do.  Because each province 

is governed differently.  And there was also availability, it must be 

available for as many as possible.  One of the early things that 

happened is that it only worked on cell phones less than 5 years old and 

only went to the I-Phone 6 S and that left 20 percent of the cell phone 

carrying population.  So there was a lot of advocacy and signals sent 

through policy and advisory councils that it didn't meet the needs.  

Within six weeks apple and Google released an update and now it is back 

to phones that are 7 years old, back to I-Phone fines which covers 97 

percent.  Then we had pillars that would guide everybody.  It needed to 

be used by as many people as possible, we needed awareness, and how it 

would help them in their communities and how it worked.  

There had to be trust, confidence the app would be private, and 

security.  There were a lot of considerations when you look at having 

more than 50 federal partners, 60 proVINGSal and more than 9 provinces.  

So we relied on having procedures documented, like how to improve a 

design change or hand off research insight to design iteration to 

implementation and verify that it met a need.  We needed to see where we 

are in the system, how would we design intentional inclusion and how 

many factors there are.  There is a diagram that represents the solar 

system, but has things like public health, Canada, health care workers, 

businesses, vaccinations, apple Google frame work, lock down, PPE, so 

COVID alert is just a small piece of that system and how it responds.  

But if there is a lack of PPE, there is a significant need because 

people need to be aware when to modify behavior or if an advisory 

council is pushing for advocacy to change a piece of technology then we 

can adapt.  We need to look at the connections in the system, what are 

the emergent needs, what are the support structures and what are the new 

rules.  So we went from having 0 users to 600-0000 within the first 

90 days of launching the app.  That meant there was a lot of diversity 

so we had to set up products and services to respond well to those 

needs.  When we started with design research, we grounded everything 

insight.  We did userability testing, user interviews, research that 

looked at whether or not somebody was going to address a need.  We 

designed inclusive designs where we served content, interaction, visual 

experience and service.  With development it centered around the 

security, reliability and accessibility on the app and policy to send 

signals around the enablers.  We also needed to make sure we had proper 

support and outreach so the awareness efforts, storytelling but also 

support activities because there is nothing worse than releasing 

something in to the wild expecting people to utilize it, it is 

responding to a health care need and then not having support.  It is a 

multi service product system, built in POT Canada's official languages 

and done that way every step of the way.  If it was written in English, 

it was written in French.  And there were five teams set up, working in 

tandem.  A mobile app team, health care portal team, server team, 

partnerships and support team.  That meant there was a lot of humans 

working on how this works and a lot of considerations to go back and 

forth to make sure we're dong things with intention that we want to make 

sure the partnerships are aligned, going through the same goals, looking 

to meet the same health care needs, looking to respond and use the 

service in a way that makes sense.  

There was also need for looking at an international collaboration.  

Because as this was happening, we were some of the first in the world.  

Right now I think there are more than one hundred COVID alert apps or 

notification apps but we needed to leverage the international community 

to work and learn from each other as we were in different phases.  So we 

worked with volunteers from the public health foundation.  We also 

started with Germany and Italy who were some of the first on market, 

policy needs, considerations they thought about.  We also did the same 

with Ireland.  We had a lot of collaboration and participation with the 

UK and the Netherlands and Canada presented together their COVID alert 

apps and how they were responding to needs and basically being able to 

leverage experiences.  The U.S. shared insights on how to share the API 

for using the one time keys provided by health care workers through 

somebody who has tested positive and how to set that up in different 

states.  In Australia and New Zealand we exchanged that information, and 

Mongolia started working on their own.  A lot comes from working 

research with real users.  On the screen I have an example of one of the 

phases of our research insights.  Our team took the time to look at the 

facets that makes somebody whole.  In this particular instance we had 

five participant, one was French, five was by link y'all and three were 

English speakers.  P what we want today know here was did the 

participant understand what inexposure notification was.  And then we 

had observation that enabled us to make decisions on the app.  We also 

created service blueprint.  The point for this was to be able to know 

what the awareness level was, actions, knowledge gaps, who were the 

owners, who was monitoring, did we test it to look at whether or not we 

were responding to the emotional and physical needs of people.  We asked 

what the health and well being and measurable outcomes of the work would 

look like in terms of impact.  This meant we were able to come over with 

some over arching insight that helped guide how we will move forward.  

We needed to be flexible for provinces because they were set up 

differently, minimize burden on workers who were already tasked, so it 

had to fit in their systems and consistent experiences for app users.  

That meant we would rely heavily on working well together.  We used some 

tools to help us.  One of those was get hub where we were able to work 

completely on the open, had people responding before the app was ever 

released trying to compile, build and respond to things that might be 

bugs or issues, but able to increase the visibility of accessibility 

issues.  Able to tag the priority level, able to say whether or not it 

came from somebody doing testing.  In order to make sure we knew all the 

time where we stood so that we can do this in a continuous way.  We also 

used the design software to help us work collaboratively.  This enabled 

our stakeholders, entire team, research developer, policy experts to all 

be in the same file and be making changes optimizing and suggesting new 

approaches.  And that allowed us to collaborate much more seamlessly 

given the amount of stakeholders.  We also used something liked 

T-R-E-L-O which was enabling us to keep track of the work we had in 

backlog, tag people, and detailing tasks and checklists that need to 

happen.  We had goals for sprint, tasks, what was being done right now, 

what was being reviewed and maybe why and what was done was able to be 

moved off to outside of the sprint to be validated.  

It also meant that we did a lot of meetings together, and they 

were imprompt TU but we also had guiding rituals.  We worked in two-week 

sprints and did retros.  It was important for us to discuss what E were 

doing and how to improve.  We were able to see blockers and respond to 

those needs so we were not stuck in a position where we had an unknown 

problem.  And that enabled a lot more clarity for people to move 

forward.  We needed that because we were navigating ambiguity.  For 

designer, I believe it means that we're able to hold opposing and 

different thoughts intention.  And that means we may not have the 

answers now and we will have to make decisions and have to root and 

ground them in something important that guides us.  We have to be 

prepared for the challenges that exist and constraints in knowing what 

we know right now.  So because there are many directions and 

possibilities that are open, we needed to find a pathway forward to the 

unknowns.  L that meant we were designing for resilience, we had to 

think about values, and ethos.  We had to identify how those assumptions 

were imbedded in practice and realign those assumptions.  Some of the 

ways were talk King about mind set and embracing curious mind set.  A 

random question may create an opportunity, so what if and what now?  

Consider multiple perspectives, people teams, coworkers, stakeholders 

and people using your service, because inclusive design and demands uses 

diversity to challenge what is possible, shifting perspective.  And we 

prompt an experiment because the road to success and change is paved 

with those small experiments and recognizing that struggle and embracing 

ambiguity allows us to move forward when we don't know where something 

will lead.  We're aim together break the cycle with intentional 

inclusion.  

On this screen I shared a graphic that is an adaptation from the 

book mismatched and how you recognize cycles of exclusion.  Why, when, 

who makes it, how it is made and what we make.  And who is going to use 

it?  But I have also added foresight here in terms of that whole aspect 

of so what?  How does this affect us, how does this change the future of 

what we're doing?  Have we learned to turn insight in to opportunity and 

how will we do differently what we know.  That was to be uncomfortable 

not knowing everything, identifying pain points and reduce the problem 

space by focusing and activating goals forward.  So we have a lot of 

opportunities -- as many as we allow ourselves to get better at 

intentional and be more intentional on accessibility.  We don't have do 

it all today or tomorrow.  What we do afterwards is critical to the 

culture change and outcomes for people.  So aim to ask powerful 

questions, provoke your thinking.  What is important about that for you, 

shift your perspective, how might this look from our user perspective, 

check assumptions, what assumptions are we making?  Challenge your 

beliefs, how else could this situation be interpreted?  And then take 

stock of what we know now and lead to curiosity to aim what is missing.  

There is great graphic on how to aim at ambiguity.  So learn from 

others, synthesize information, communicate deliberately to move between 

concrete and abstract.  And then when you can craft and build 

intentionally, you're designing the design work.  You need 

intentionality prompts, notice and reflection, able to identify and 

share and hold space STO do that work and process that so you're 

balancing quick action with thoughtful reflection.  

I have basically taken a design process here and a traditional 

prototype, but I have changed to emphasize and understand.  We can't 

always empathize with somebody's situation, we don't know what it is 

like to be them.  So hoping we will understand all the situations that 

somebody is in is not really true, but we can aim to understand.  And we 

can understand by knowing the power, the mental models, context, the 

partnerships, intention and identity.  We may look at people aging, 

mobile DWOISs, older technology, primary language may not be English.  

And then people that are maybe deaf or hard of hearing, low vision, 

blind, have episodic disability.  Maybe they have low bandwidth or 

mental health condition.  

So we need to make it a safe space for people to give feedback, 

and by being flexible on when how and whom, enables the trust and 

willingness of the engagement with the team.  In those retros I talked 

about that we did as retrospective, we would use things like slack and 

send direct messages and getting a pulse check if they felt they were in 

a safe space, if they thought they could share most thoughts.  And if 

they had a word or phrase that could share their experience on how the 

week was, the retro, if they were heard.  We give them multiple ways.  

They could do it aanonymous, slack, video call.  Or somebody else to 

give that feedback to.  That is the core of how we work together.  And 

then how do we facilitate the backlog.  What is it?  It is a list of new 

features, bug fixes, infrastructure changes, or activities the team may 

need to deliver for specific outcome.  They need to know they're 

understanding at every level.  If it is not in the backlog it is not 

going to be worked on.  

User rise findings and insight, and technical and design open 

source channels.  Then we have to look at how do we prioritize a backlog 

like that?  Is it public health priority?  Do we have proof the user 

needs this or are we solving the right problem?  How urgent is it?  And 

is this creating debt?  That means we have guiding principals, plus 

sources and prioritization equals a backlog.  How often do we do that?  

Every day.  

One of the reasons is to make it accessible for every one.  Some 

people ask why do you need to make it accessible for all?  In Canada it 

is pretty diverse.  22 percent of people identify disability, and more 

than two percent of the population don't speak English or French.  So 

service design becomes important and intersects with inclusion.  An 

example of after we released the app we had exposure windows because we 

had new information from epidemiologist and we could say you have been 

exposed on this date or this proximity and this is how long your 

exposure would be.  

This came out of some of the research insights and the fact that 

we were using a continued iterative approach to accessibility.  So at 

the onset we created an accessibility plan.  We started doing what we 

coined as an inclusive design review.  We did more than seven of them in 

the 45 days before launch, two after launch.  And because we realized 

the team was working so closely together, they decided to address 

service inclusion decisions, interaction decisions, without having to 

have it be separate.  More than 70 accessibility issues were answered 

before the launch and more after the lawn FRP.  There are less than five 

accessibility issues now, and we do manual and automated testing as we 

ship and deploy new things as well as when it is being built.  That 

continuous testing features and functionality help us recognize this is 

a team sport.  It is not all on developers, not all on designers or 

researchers, it is the whole collective of a team working towards that 

goal.  

And some of the things that enabled us to do that is to develop 

accessibility triage tactics.  Decisions that were being made, and the 

issues were tagged using labels to support that visibility and scope, 

but also empowered people to say I have a problem here, this needs to be 

fixed.  That enabled us to get prioritization and to not have that 

become something that fell off or got pushed to a parking lot and not 

achiefed.  

Some of those tactics were upstream, so we had worked and are 

working on a COVID shield.  And we were referencing upstream issues so 

they could pull the fixes back up.  We had low pry errorty issues, 

medium priority issues which do not impact functionality, and high 

issues which were critical.  This work flow was created to support 

people who were being on boarded and the accessibility of beta testers, 

new issues that needed to be addressed.  It kept access about visible 

every day.  It supported conscious decision making in terms of 

priorities for the team but also identified where we may need better 

resources and support structures.  

It also lead to some big wins for government.  We have a public 

accessibility statement and a full public accessibility report open.  

And a service design lens that was applied with accessibility touch 

points.  Our beta testing included more than 6 thousand users, some that 

self identified as having a disability.  We wanted to make sure that an 

accessible service would include all touch points.  When you call 

service Canada, there is a TTY number to call.  It comes over to the 

Canadian digital service if it is something we need to respond to.  

There is an e-mail, a get hub repo with open feedback channels, so 

different ways in which somebody can engage and it becomes multi modal.  

Because we were working on those multi display nare teams, we needed to 

make sure we were also looking at inclusive governance.  What is 

inclusive governance?  It is essential to long term sustainability 

because governance is only inclusive when the efficacy is measured on 

how well it engages all.  What is the service, the system, how does it 

affect uptake?  The design is a pillar of the accessible Canada act and 

there is a need for different approaches with different demographics and 

the apple and Google frame work means sometimes we're more reactive 

instead of proactive because frame work changes the DWIS.  So priority 

is determined and guided by health care needs and enables us to respond 

in an agile way to fix, build, implement, repeat and make things 

sustainable in terms of core functionality and sustainability.  

We are able to leverage that every day, and we advance responding 

to the diverse needs of the populations.  

Inclusive governance sends signals for availability, accessibility 

and adoption.  It allows us to better pivot to we can serve the 

populations better.  We need to recognize how the echo system performs 

and directly intersects.  L on this screen I have a map of the 

approaches we discussed today.  Design reviews, userability from diverse 

communities, open issue queues, testing and things like that.  It also 

highlights things we could have done differently or better.  One of 

those is earlier tech intervention around automated accessibility.  It 

would have been great to have that set up from the first time we set up 

the build and then having to work backwards.  

We needed to re-evaluate earlier with stakeholders to look at that 

from the day we started and how we would measure accessibility and 

inclusion.  What we ended up with is more than 11 thousand support teams 

in the last, 6 or 7 months.  Hundreds of articles about access and 

availability, because when it first launched it only went back to apple 

or I-Phone six S.  

An e-mail address has been KASHTHed more than 26 times, and 

highlighted a key need.  Over half were related to emergency response 

notifications that you get from cell phone providers about COVID in your 

area or amber alert.  We were able to reach out to the departments 

responsible for that to address other issues and it allowed us to 

leverage a more whole governance response.  Key areas we had to consider 

were the types of work that needs to be accomplished.  We looked at how 

we worked together, how we might have governance, but what is the actual 

app?  We started with content design and needed to know that trust 

depends on understanding.  People who downloaded the app needed to 

trust, and if not they weren't going to use it.  A lot revolved around 

the people and the people they were with and places they go.  Most 

people think about virus transmission and it is tied to people and 

places.  If the people trusted the app would not track them, we had to 

show that, that the app would record exposures without tracking 

movement.  In other words we had to change the way of thinking of how 

the app actually worked.  So there was some over arching principals.  

Inform just in time, give just enough detail, spread out the density of 

that meaning and write it like a real human.  That meant to be 

conversational, not to give walls but text as people needed it as they 

move through the different screens.  Then we also looked at 

illustrations.  So there was a lot of feedback that came in about how 

people perceived information and what to do when you're looking at 

something that might be a bit anxiety inducing.  Because we were 

striving to be approachable to as many people as possible, we needed to 

have the insights around this.  Those research insights allowed us to 

change the on boarding screens and add some illustrations.  Some 

examples would be what is on the screen now.  The ultimate goal for 

these designs was to show a range of diversity in order to allow every 

one to feel like they were included in part of this experience.  So we 

needed some principals, create a clear and mobile and friendly concept, 

friendly storytelling.  We needed to make sure whoever viewing the 

images didn't feel discomforted or distraction or burdened.  We wanted 

to make sure it was accessible.  And that it was more universal, simple 

graphics understood by as many as possible.  They may seem like large 

ideas, but they were guiding concepts on how we would explore and 

visually represent the information.  Showing diversity beyond hair, hair 

is one of the most wonderfully diverse thing about us but also one of 

the things that can have someone judge us really quickly.  So how do we 

show there's a lot of diversity in something without having it be 

represented just solely by hair.  We also thought of things like using 

minimum color pallet.  Part of that was the pigmentation of skin color 

and the way your eyes move to different levels of contrast.  So the lack 

of contrast leaves little detail for eye to see again, bouncing your eye 

back the people with different contrasting details, for example those 

with lighter skin, making them the focal point of illustration.  

We decided not to give lighter characters pigmentation.  The 

second is the screen in on boarding, about privacy being safe.  One of 

the things here was we wanted to make sure that people needed to 

understand the intention of the service, and if nay didn't it would lead 

to mistrust.  The consequences of not understanding or following the 

rules of the service transaction can lead to negative consequences and 

prevent them or us from meeting our goals.  How do people move through 

the flows of what we're representing, what is the experience when they 

go from one thing to another and how are they interacting with it?  And 

so when you open your phone the look at something like COVID alert, 

there is always a moment of anxiety or anticipation.  Receiving exposure 

notification will not be pleasant and there is no real way around that.  

Ultimately the right thing to do as designers is to be as gentle and 

supportive as possible and guide people through the experience they're 

going through in this pandemic.  This is why in addition to giving out 

110 keys, we created an alphabet that took out letters like W for 

whiskey and instead used WiFi.  We want today have a universal story.  

The main screen contains -- all the screens use a hand.  You have no 

exposure or all set is a thumbs up.  If you have the agency and autonomy 

to gather more comfort from what you're seeing versus something that 

might be a little more scary or alarming.  

When we use that, we wanted to make sure that the first motivation 

was to help the human rather than machine.  Instead of helping the 

machine communicate status to the human, we decided symbols would be 

used by the hand.  So as complex as it may be, what matters is how do we 

translate it to human language.  When there is nothing to report, it is 

a thumbs up says everything is well.  But if there is a potential 

exposure, there is a small stop sign with hand up to seek guidance.  The 

only deviation from that in the app is when we needed a role reversal 

and there was something wrong with the machine and the human needed to 

intervene.  If you had Bluetooth off, airplane setting on YUR phone, you 

will get a round circle with an explanation point that is red indicating 

that there is something that needs to happen in order for the 

application to work.  

And this particular screen goes through some of the flows of the various 

screens that were created.  The idea is that COVID alert is there to 

guide people as a collective but most importantly as human beings with 

feelings during a pandemic.  

Then we get to development, we have gone through what content, how 

illustrations may be ready, experience of interaction.  When we got to 

development we were late before we started but we wanted to make sure we 

had the space.  IOS 13.5 had the frame work, because Google and apple 

pushed that.  There was a lot of media coverage talking about delays, a 

significant amount of pressure that we have something and that we 

respond to needs.  And there was a lot of work to do.  The proof of 

concept on how we might do this worked so we needed to be able to move 

forward.  Unravelling somebody else's work is a big task.  We need today 

do that in a way that was meaningful.  So we coded it in the open.  We 

wanted to thank other countries that allowed us to stumble together and 

people can fact check our claims.  

When we tested the app, we built our app on the foundation of COVID 

shield.  That meant that there was already a series of volunteers 

supporting in the development.  We had beta testers who turned in to 

advocates and QA processing became second nature.  Manual testing still 

haunts us because it was one of those things where Android devices 

worked across a variety of different O-S installs and that meant the 

experiences was different.  

We wanted to think in out comes and impact and make sure everybody 

is aligned on goals and values.  Understand impact of actions and carry 

the weight together.  You have to let research and health care needs 

serve the product.  We were able to strive for that step every step of 

the way and bring other folks in that way.  Working in the open takes 

practice, you need strategy.  Getting your government to work in the 

open, you don't want the practice when it is large scale or public.  Be 

as timely as possible when responding to issues and set priorities, 

sharing code plus you shall shoes helps every one.  We have been able to 

look at others and discover common problem and bugs and helps us improve 

functionality and accessibility of the app.  What is next?  We're 

starting to look at how we do this in terms of product planning and 

accessibility and inclusive design work flow and sparked interest.  

Now we are looking at ways to create and grow.  What are your 

product accessibility goals, how will we measure success, who will 

participate on the team?  What are we missing?  What are the potential 

obstacles?  Do we know the costs?  And what do we have right now?  But 

it also lists tools and resources that teams can use, or look at testing 

that they may have had manual testing and they have done testing to 

affect people that had disabilities, cross browser, fire fox, Safari, 

did we check things for manual testing like keyboard or reading order or 

if the alt text fits the content?  

I will share this separately afterwards in two outputs.  One is 

mural and a Google doc that breaks it out.  

What we want to learn now is how to improve access to COVID alert.  

We are still doing ongoing research, so if anybody wants to reach out, 

they can.  We're trying to learn about experiences with bandwidth, 

phones and computers, how it intervenes with health care, concerns with 

the app and anything else.  We would love to hear from anybody about 

things like that.  And if you want to learn more about our process and 

work, you can check us out at digital dot Canada.  

 

>> What research did you need?  

 

>> Well, the first example only had participants and then an ongoing 

series.  Basically every week a dedicated researcher was doing new 

research.  What that enabled us to do was we decided before we would 

launch that we would do a small scale beta with friends and family to do 

snowball research to get a bigger ball and then that insight lead us to 

there is more to do, and we had a three week delay and a large scale bet 

that with 6 thousand people to get a much more impactful series of what 

are the things people are experiencing, what happens with different 

devices, are people understanding because that would be crucial to the 

efficacy.  

 

>> I design software, do you have any idea on how to contact medical 

professionals, those using electronic health systems to test products?  

Do you have any automated tools you may suggest?  

 

>> We have not used any automated tools to my knowledge.  We have tried 

to look at ways to use, especially being the government in our case.  

There are some organizations and companies out there that can help.  I 

believe fable and nobility do that research where they can find 

participants from a variety of different backgrounds.  There are ways to 

find that through, out sourcing.  

Often it is the ways in which you engage and how many places you 

are looking and where will you find those people?  Because if you're 

looking for them on Twitter and they're not there, you have too find 

them.  You have to have an alternate approach.  A lot of that helps if 

you can go through community support initiatives as well, but there is 

also the balance of burden on those in this type of timing.  

 

>> Makes sense.  Thank you.  When internationalizing the application, 

was sign language for deaf people a consideration?  

 

>> I would say yes.  But also how we would do that became an interesting 

conversation in how do we include everybody?  How do you include things 

like sign language in English and French in an application, what are the 

best ways to do that and I'm not sure we have come up with a good answer 

and something we would love to learn more about if somebody would like 

to reach out.  We have done some research with deaf participants, or 

deaf and hard of hearing, but right now the material that are online on 

the websites do have ASL in some of the video content, but not 

everything has been interpreted that way.  

It is definitely an area we can improvement 

 

>> Sure, if anybody has ideas.  

How did you reach out to your native populations?  Did you to work 

through cultural sit YAGs, native, trust?  

 

>> There is a lot of distrust and mistrust from indigenous experience 

especially with working with government and research.  We did look at 

the policy implications and the constraints of government and how 

government is supposed to do it, because there are ways we should engage 

those populations.  And I think for my knowledge right now the ways we 

have done that is through the community facilities located on reserves 

and things like that.  I am not sure of the numbers, but I know we did 

that capacity and it is an area that is difficult to ensure you get a 

good consensus of population.  

How inclusive you are in your approach, is it something you're 

able to allow them to lead more of the research on or are you in a 

position to do that.  And in this case, because we were responding 

quickly to critical needs, it was something that happened but didn't 

happen as frequently as maybe it should.  

 

>> Okay.  Can you explain how the federal approach was decided for this 

app?  In the U.S. it seems their only exposure notify KAGS applications 

if an individual state provides them.  

 

>> So that's one of the reasons in Canada that not every province and 

territory on boarded.  We have a similar situation where each province 

has their own health ministry, and because they have their own health 

ministry they have their own decision makers, people that have to be 

bought in to doing that.  The federal government decided they wanted to 

and we started with launching the just one province, Ontario July 31st, 

then Quebec, Newfoundland, Manitoba and then continued until we had nine 

provinces and one territory.  There are still two province that have not 

on boarded.  They those last two cannot use it when he will, but if 

somebody from Toronto flies to Vancouver and the person from Toronto was 

later diagnosed, they will get an exposure notification.  The one gap is 

that the one time key or thing that let's other people know they were 

exposed is given through the health ministry.  So it is a call, you have 

tested positive, here is your key to put in the app so there is layer of 

security and intentionality there which is why we have the health care 

portal.  Some provinces are doing that so they don't have an online 

system, and others are using API and grabbing the server.  So we had to 

use different divergent needs.  Because each state operates similar and 

some counties, it is difficult to mirror that approach.  

 

>> This is probably our last question, so thank you to everybody for all 

the questions and thank you for your time.  I see the application is 

built with reAK native.  Did the team face challenges with this like 

accessibility issues being present on one platform and not the other?  

 

>> Because we were taking a repo that already existed from somebody we 

had that dictated because some of the work was done.  On the development 

side we were already behind the curve, we had to go with that right 

away.  But it became really important and highlighted really quickly 

when when he started looking at adaptive technology that there were 

problems.  So we spent that six weeks, 45 days, with four testers from 

health Canada that were testing new iterations, new commits to the 

repos, new builds of the app that were being shared on Android and 

I-Phone.  We were doing it with simulated browser stacks at some points 

because there were problems with focus states and being able to read 

content that was underneath when a menu was expanded.  So there was 

definitely a balance to strike there and it became important for that 

accessibility.  If we had waited until the end, we wouldn't have be in 

the best spot.  

 

>> Thank you.  I will say thank you no everybody involved and enjoy the 

rest of axe con.  Thank you for spending this time with us.  

 

>> Thank you.  

Type: Breakout

Track: Development

Championing a culture of accessibility can be difficult. It is especially daunting when you are the only one in the organisation who seems to care. In this talk, I will cover different approaches that you can take to improve the accessibility culture of your team as well as the accessibility of your products.

  

  >> Thank you, Ryan.  Hi, everyone.  Welcome to Integrating Accessibility into the Software Development Lifecycle.

So who is this talk for?  Had it's for everyone involved in development of products from product developers to product managers, product owners, UI designers, UX researchers and testers and anyone, all stakeholders even investors and founders and thon technical founders-- everyone should be -- this talk is for every one of you.  If you're in the audience-- I'm glad you are here.  A little bit about me, my flame is Segun, I'm a software engineer, I live in lagos, Nigeria.  You can reach reach me on Twitter.

What is a software development lifecycle?  It's the series of snaps that are used to create software products.  And the commonly defined sets are first of all, identifying current problems or product requirements, come up with a plan then design based on the plan and then build it that will transition from building to testing.  Testing what has been built fulfills all the requirements and solves the current problems.  And if our tests are satisfactory, feature or the product or the solution goes into maintenance mode.  And this is a cycle.  So it's repeating and going onto the  next-- and we have different approaches for that which is beyond the scope of this talk.  And here's infographic showing an alternate version where you have the planning and analysis of the problem or analysis of whatever you came up with during plans and you design and implement test and integrate with your current product.  So and then you move on to maintenance again.  So the cycle continues again.

So what really is the problem?  From the steps defined earlier, they should be able to capture all the problems in a software product and solve them and address all, any problem.  Because if you can identify the problem then we can solve the problem in most of the cases?  What is the problem?  The problem really is accessibility is usually not defined as a problem.  Most of the time, the product will go into product lifecycle and we identify all of the problems inned product and things we want to solve and ignore accessibility.  So even when for large part of the population for for users, a product is basically difficult to use or worsen is their quality of life, we in the team can consider that product and feature done while negatively impacting our audience.  Why does this exist?  Why do we have this problem?

And for the most part, in my experience, it's usually just the fact that, if you do not experience it, you do not know it.  So people creating products do not suffer from debilitating disability.  So we're blind sided from the realities and software engineers and designers who do not even know that there is a thing called a screen reader like I'm not exaggerating.  That happened last week while I was reviewing some code and explaining why the code needed to be refactorred.  And this developer, engineer, asked me what is a screen reader.  I assumed they knew what I was talking about in the comments.  So I had to get on a call and with them and show them what a screen reader was.  And asked me what is the point of the screen reader?  Oh, yeah, there are people who can't see the way you and I can see.  There are people who are blind and they still need to interact with software.  13456BG they need to mainly interact with software more than you and I need to.  Because for example, I can walk down to the store easily.  * it's a lot more convenient for someone to avoid traffic if they can see or hear the traffic oncoming.  But for someone who can't, they can easily order grocery,ing order shopping from home.  And for them, software * is more important and we need to build it to where it caters to them.

So because -- the problem is because the majority who are blind sided by this problem, from this reality, we-- sorry.   I'm going to go over that again.  Being the majority and being blind sided by this problem, our biases and ignorance has shifted development culture and values and what is important.  For example, what do we define as a good user experience?  A lot of time someone says sleek UI, fluid animation.  And these are all great and when done properly can be really be access I am.  Often times we define these in a way that could be even-- unfruitsful with people with disabilities or other problems.

So this is why the problem exists.  And I'm going to paint a scenario, Miriam needs to get groceries.  But she can't go out to get them herself because he's visually impaired.  And (READING).  I live in Lagos, nitrogen nitrogen.  This is typical.  And also we're in the middle of a pandemic.  She decides order online.  And fills the cart with things she needs, jumping through many hoops because the site was not designed for her in mind which are-- because she's using the screen reader or babe the text is too small, not enough contrast.  It can he ee numb rabble.  She tries to check  out.  Someone who is a screen reader can't check out because the site, the check out button is not really a button.  And so * it is not-- it can't take focus from a screen reader.   And while this might seem an extreme scenario, it is a real one.  We had a few-- we had the lawsuits for Domino's pizza some time ago because someone could not check out.  We've had several cinema cases in different countries.  And these are common.  These are common.  Sometimes it's a closed button with an icon and-- and it works if you have a -- only if you use a mouse.  If you can focus on it.  And even at that, it is not enough padding around it to make it  tappable-- so people who have big finger iters or people who have tremors like people who suffer from Parkinson's  disease-- you're making them focus on something very tiny because that's what the design says or because maybe as a developer you don't realize that there are people who interact with the web but not in this mainstream way of using, tapping on a touch screen or clicking the mouse.

So what failed Miriam in this scenario is did the UI developer?  The product owner?  Testers?  Had everyone in this software development lifecyclehas failed her.  When I prepared this slide, I said in a different scenario I said it could be -- emergency service.  A few weeks ago there was a news on Twitter that the vaccine sites in the US were not accessible to people with disabilities.  And it was being investigated.

And that's a real-world situation there.  I don't think-- it was inspired by a evil team or evil developer but built by people that didn't depend on Assistive Technology or on very accessible sites for them to function.  So they-- affecting people in realtime in real-world and the quality of life of people.

So how do we fix this?  If you're here, you obviously care about accessibility.  So you will be-- you are the champions that are going to help champion the new culture of accessibility of building accessible products.  And you won't be able to do it 0 alone.  If you're the only person that cares about accessibility in the company, it's going to be an up hill battle.  So the greatest weapon at your disposal would be to educate others.

So yeah.  Our greatest weapon is to educate.  We would need to be patient and kind and gentle even though we also need to be firm while getting people in the right direction.   It's not going to be easy for some of us.

So where do we tacklethis problem?  I have six steps of lifecycle.  At what point do you model it?  At the  beginning-- [Off Mic]

accessibility encoded as a screen reader I should get to log in.  As a user, I need to Zoom in the screen to 200 percent encoding that in the requirement.  And sometimes those requirements are not -- are not given by developers.   Sometimes at the design change, you have to ensure that, before a design moves forward or is under the developer is accessible or explain what are the problems.  It shouldn't just be oh, our site is not fancy enough or sleek enough.   Yeah, while that is important because you need to get people's attention.  You need to use animation to direct people's attention to the most important, you should also be able to, as we're gathering those requirements we should be gathering the accessibility requirements as well.  Okay, for yeah, we need more fluid animations but also we need to be able to turn them off or opted out of them.  These should be requirement to creating animation.

 

* we have a request to create, let's say, let's say a  banner, for instance.  Okay, part of the accessibility should be like, whatever message or call to action is also possible to non-mouse and nonvisual users, keyboard users, switch users, screen reader users, all of them can interact with these things and can actually get to the same goals which comparing things-- so to have this holistic solution, accessibility has to be a first class requirement at every point of the software development lifecycle.

So it has to become what, part of what we think of when when we do it.  It's not something we try to hook in when we have a problem or when we get a lawsuit.  It should be part of the whole process.  When we're seeking what needs to be improved and can done, we should be seeking how these are impacting people who have-- I like to call it alternate experience of our products.

So notes from my personal experience because I have worked with teams who, you know, had no idea what you're talking about when it comes to accessibility.  And I've had some-- I have experienced push back at some point by well meaning people.

I remember two years ago, I was leading a team.  And the team were junior developers.  And part of the requirements was every feature has to be fully tested with screen reader and keyboard to ensure everything is accessible.  And one of the team members said to me, why are you doing this?  I  said, yeah, because people-- not everyone interACTs with applications the way we do.  And he said-- I said, blind for example, if you're blind, you cannot use a mouse and a screen.  You need another way of accessing the work.  He said, honestly, he said, but I'm not building for the blind.   And I had to educate him, take 30 minutes sit him down and explain you're building for the blind.  The blind is-- the blind are required-- should enjoy the same experiences or similar experiences -- you need to do the same thing as you and I.  And I said-- I asked him, if something happened to you today and you lost your sight, what would you spend your time doing?  And he never thought about it.  I said, more than ever, you will need digital experiences because you'll be cut off from other physical experiences.  You can't go to see a game but you could experience it from home on your audio.  You can-- because your interaction in public places are limited because you can't easily protect yourself especially in a place like Nigeria where there are provisions for people who have come disabilities.  Yeah.

So for such people, digital experience has become more important, more imperative and it will be just terrible to ruin that for them.  So we need to take more responsibility with that.  So yeah, be prepared-- sometimes it's just sheer ignorance like honest, innocent ignorance.  And that sometimes, on occasion you have a person who just doesn't care.  But in my experience, they are like the exception.   When you make your case and make it with empathy.  Try to understand where you're coming from.  One mistake people make is trying to vilify the opposition, hey if you don't do it, you're an awful person, a terrible person.  And sometimes people think accessibility requires more effort than it does.  So they basically say, oh, we don't have time for that now, so we can come back to it.  And especially where they don't have, we're don't don't have repercussions is to do it immediately, you're willing to understand where they're coming from and educate and guide them because a lot of times you can get good accessible, you can go far -- it's like the-- principle.  We've-- 200 percent of the effort you can get 80% of the good result.  Sometimes you might have to settle for good enough instead of excellent.  But it's-- but still -- still keep pushing.  Because the idea is to change the culture, to integrate it at every step.

And the more-- as the culture changes and more people buy into the idea or more people begin to get involved, for example, if you had QA testers, testing -- or never tested for accessibility, start testing for accessibility.  They can find bugs for accessibility and become things that need to be done.

Designers who are now accessibility conscious and begin to consider that, maybe push back when there were requirements to do things that don't make sense like disability.  So getting -- that's why I said earlier, the biggest weapon at our disposal is education.  If you can educate and get more people to buy into the idea, then you can have like-- you get people to buy into the thought process, into the culture of considering people, considering accessibility best practices all the way, then sooner than later it becomes ingrained in the product and helps people get better experience with the products.

So sometimes what arrangements do you have to make?  How do you convince people?  For example, earlier earlier as a team lead I had to sit my team down and explain to them.  And I was able to say, well, these are the-- [Off Mic] so I could do that.  If it doesn't meet these requirements it doesn't go forward.  And that's actually one of the great things when the team lead, when the person, people leading teams or key decision makers are conscious of accessibility and the need for it and best practices.  So you might be a developer and you don't make toyings.  You'll probably be an engineer or designer-- engineer designer and you don't make the big decisions.  But if you can get someone higher up to understand what you're talking about and show them how achievable it is, then it can become a part of what the team does.

I'll give you an example.  I remember in had 2018 I was working with a team and asked, how long is it going to take to build X?  And it's an estimation.  Because they knew I was all about accessibility, the product owner asked me, how long is it going to take if we leave out the accessibility and come back afterwards.  I said it will take the exact, same time.  And I said, because making it accessible from are the get go takes like maybe just a few extra minutes for each step.  So it's really not that much many of an  overhead.  So I gradually, this kind of question just disappeared because it just became, okay, we're going to make it accessible from the get go.  And that was a way to win my team over or like, or the manager.  And so it became part of what the team did.

So if you're like a team leader like I was then, you could basically say, give technical arguments.  This is what we do here.  This is the standard for us.  It's-- sub participate if it's not accessible.  This might not be a good argument to make on the business side, this is a good argument to make with the team saying this is how to build products.   This is how to build UIs and get the buy in of team members and colleagues because you're setting what is the technical argument here.  This is -- if you don't build this way, you're not following best practices.  And yeah.  Technically people like best practices.  So the other one is moral argument.

The moral argument is that it's just the right thing to do.  Like I said earlier, for people who have debilitating disabilities, experiencing the world like those who don't have disabilities is not an option for the most part.  For example, if it-- for people who are wheelchair bound, I was talking to someone earlier, I said in my country, banks are required to have a certain level of security.  And that security prevents wheelchair users from accessing commercial banks.  So a wheelchair bound person can't go into the bank without someone's help.  They simply can't go in without someone else getting them through

>> Other means, regular means they can.  I don't know how they go to the bank if they do.  And so using mobile bank-- mobile applications for most banks in Nigeria have mobile applications that people access most of their banking transactions activities from the phone.  For people who can't easily into the bank, such software is very important for their day-to-day experiences.  And yes, it's very cash society, still doing leg bank-- credit cards are very- kind of like exotic here.  We don't even do credit cards.  So yeah, still you need to do cash based transactions with people who are disabled can do that from the come format of their homes.  As a matter of fact you have short codes you press in your phone that work without an internet and people can do transactions from their banks with short codes on their mobile phones.

And the tech that follows that has made life easier.  Now, imagine such applications are built in a way that people who are disabled can't use them?  That's just -- at this point it's becoming evil.  So yeah, so that's why it's the right thing to do.  Our products should be built-- we shouldn't marginalized people who are already marginalized because of their circumstances.

Now the business argument, what you can make if you have to convince the people who sign the checks, for example, this is in the UK, there's something known as the purple pound which is the spending power of disabled people and their families.  And it's estimated as of 2020 to be around 274 billion Euros.  -- pounds.  It's pounds.  UK.  Yeah.   And that amount is rising steadily.  So that's a lot of money.

And it's estimated that about more than 4 million disabled shpers click away from a website because they simply cannot.   You go on YouTube and search blind shopping.  There are a couple of people who blind bloggers who are have their experiences of shopping online.  Many times at the actually get to help them.  Many times it's just -- it's just more work and makes them less able to do anything they want to.

And also another argument you can make is that accessible sites tend to have-- can drive better traffic to the company and product.  And definitely there's a legal part, I can split makerring a different argument dark -- people who sign checks don't wants legal problems.  So let them know that, hey, not only are we doing the right thing?  We're doing this is protecting business from lawsuits, from unnecessary expenses and as a matter of fact, refusing to-- making a product accessible is another thing you leave money on the table.  Like I said earlier you might not be able to win every one at every time.  You must understand that still, while you need to do to work, you need to convince people.   It's okay if all you got was some but not all the way in.   Because while 100% accessibility, some accessibility is still better than no accessibility.  So if you don't get any enrollment, just keep doing the good work only your own.

Keep adding your bits here and there.  If you're a designer, a little bit here and there.  If you're a product owner, a little bit here and there.  Product manager, same.  Developer, same.  Just keep doing your bits and making someone's life a little less terrible.  Thank you.

>> Fantastic presentation.  Thank you.  Really appreciate your time.  I think everyone in CHAT is very much identifying with your experiences.  You know, I think your message of education and especially patience seems to be really resonating with folks.

Some folks may be not having the patience that you have.

>> Yeah.

>> We do have a few questions in here.  And I'll just remind our viewers to put them in the Q&A section.  And I'll make sure the top questions are addressed quickly here.

So the most popular question is something you, I think you really just finished talking about, but might be worth reiterating.  So this person's asking, when dealing with external stakeholders who are pressuring for fast, for  speed, foreign the release of a coming service, what strategies can you offer to help soothe that person into a position that you know, doing this right will actually take less time in the long run.  What other strategies do you have?  I know you mentioned a few.  But with regard to, I think the personnel you're dealing with internally, maybe you can take that angle to this question.  Which personnel internally are you dealing with to maybe have some success in this way?

>> 

  

  >> Okay, um, well, so when I talked about my product owner a few years ago, basically said, um, can we refuse to do the accessibility part and focus on the functionality?  And how long is that going to take?  And I said, it would take the exact same time, right?  Because, I think, like I said earlier, the divide is usually that people think it will take more time to make something accessible.  And sometimes yes, it does.  But it's about giving people the idea that, like on understanding where they come from are.  Okay they think it's going to take more time.  They think that accessibility is going to make it faster and access slowing us down-- you need to understand that okay, this is where they're coming from and this is what you think about this problem.

And from then, you decide, okay, who am I talking to firms of all?  Because like I said, there's an argument made for different people.  If it's a technical person that is that said, oh, yeah, do it fast.  Build it fast and let's go and we can come back here to do it.  And then you turn -- one example, like I said, your argument asks to tailor who I'm talking to.  You can let them know, hey, this is not good quality code.  You do know that, when we have technical -- it will slow us down thought long run.  And that could-- that could become a business problem because we get-- because the product -- the company gets sued because we're-- laws, depending on the country you're in.

If it's-- if-- I know people say, yeah, let's just rush especially when you're working with start ups.  Everything's always like-- some cases, no matter what you say, whoever you're going to talk is just not going to listen.  And that's why I said that, if you can't get buy in, you still do the bits you can.  You might not get it as far as you want to get it, but like I said, with the resource tricks you have, you can still have some accessibility out there.   You can still lay grounds work for your improvements even though you may not be able to get 100%.  The truth is, if you don't do it, someone else who is going to do no accessibility at all and worsen people's lives.

For example, we had this vaccine stuff.  We probably wanted it out there because old people should be vaccine natures.   But in the process -- I have no inside information.  But in the process they're basically cut off a lot of people who need in even more of-- if this was a private company, they could be in a lot of mess.  I think it was-- the government site -- websites and they were -- I don't know the process in the US.  But there were ways to deal with that.

 

 

So yeah, so what I'm saying-- I'm jumping in different places.  Some of what I'm saying, you have the argument of who you're talking to and decide which strategy is more likely to convince this person.  Is this person more likely to relate to-- if you're talk to the tech person -- the problem of technical-- [Off Mic] but it can become something that you have to agree entirely to be able to make accessible later and that is a big problem for the team, for the product, that's is going to take a long time.    make the argument clear to be able to win them over.  Someone on the business side, tell them what they're exposing themselves to, what money -- what they're leaving-- money they can be leaving on the table as well as the litigation they could be inviting.

>> Appreciate that.  I think there are actually a lot of questions similar to that one.  And I think you helped answer quite ail fuel in your explanation.  Thank you.

One question I'm hearing here, and you alluded this to a little bit.  You in the United States we have the Americans with Disabilities Act.  We have section 508.  We have a legal requirement.  You mentioned the Domino's.  Would Domino's with practicing legal disability if not for that lawsuit?

You can lead with the carrot or the stick approach.  And the United States the unfortunate reality is most folks practice digital accessibility because of the stick approach.   Without an ADA equivalent in Nigeria, how is your situation different?  Are you -- do you only have the carrot option available?  And do you find that to be easier or harder to tell digital accessibility?

>>

  

  >> Yeah, I think here it's more of the carrot than the  stick because we don't really have much many enforcement in terms of the law.  One of the advantages-- I won't say advantage, the uniqueness of my situation is I have had experience to work with people all over the world and different continent.  The difference in the experience all over the world and legal provisions.

But yes, how do you-- how do you incorporate that in  Nigeria?  This is one big problem with start ups in Nigeria.   Everyone's trying to rush to market and get something.  And many developers tell me, oh, uh, I wish that they're more interested in accessibility otherwise they will be able to build more accessible products.  And I said, if you can't get anyone on your side to ensure accessibility, you might not be able to get management onboard but you can get the team onboard.  You can get the design team, the developers.

For example, I worked with a team that had, the brown color for the company was like light green -- so sometimes we had their logos and text in lemon green on the white background.   And I found out that, hey, this is a nightmare.  Color contrast is off.  We need to adjust the designs to make it better.  And then we re-think the design and come up with color contrast.  And there were other things there, subtle things that are not communicatedded in design, for example, application stage.  So while building as a developer, I have to factor that in and being also, adding the engineers I was able to point them out doing code reviews and doing personal testing.

Like at some point you might not be able to get like-- you can't -- or you don't have the time to get everyone onboard.  But if you're getting one or two people and they would go onto get somebody else onboard and gradually -- some  people-- and sometimes they reach out to me individually and making a product accessible, making it respect  accessibility, best practices.  And while the industries are a bit younger than the US, I'm really excited the future here.

>> I love that mindset.  I mean, every individual barrier, you're able to remove is a win, right?  That's one less barrier for someone else to encounter.  So great mindset.

Okay.  We've got about four minutes left.  Let's see if we can find a question that we can answer quickly.  Let's see oh, how-- so I don't know if you want to answer this for your current role or past roles.  How long did it take you to make a significant impact or a measurable impact?

>> That's-- that depends on the team-- yeah, like,-- yeah that depends on the team.

>> That's a bad last question to ask.

>> Yeah.  Because it depends on the team, how bad the situation is.  Yeah, but there have been-- if you're going to make some impact -- and notice that the product is a bit more accessible, maybe within the first month if things were not really in place because simply by talking to the  designers, maybe you get a design -- can I get focused screens maybe?  Can I get-- [Off Mic]

And then design goes back and get you back and then you begin to, you know, where-- Semantic HTML if you're a web developer.  It might not be a huge result but it's additive.   And in time it becomes more important.  Like I said getting more buy inasmuch as possible is going to like make it exponentialal not just additive.  That's how it works.

>> Great.  Thank you so much for your time.  I really appreciate it.

Everyone in CHAT loves you very much and identifies very much with what you're shared today.  Really appreciate your time.  Everyone in the audience, thank you for attend being and character about digital accessibility.  Hope you have a great rest of the day at AxeCon.

>> Thank you everyone.  

 

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.