(no subject)

Today attended https://axe-con.com/ an accessibility conference from deque systems

Keynote 

The Future of Accessibility

by Vint Cerf https://en.wikipedia.org/wiki/Vint_Cerf (TCP/IP co-developer)

"1 billion people in the world have a disability. Every time a person with a disability is assisted, you are affecting another 6 billion people because the rest of the world interacts with people with disabilities. When we assist a person with a disability, we benefit everyone."

I didn't know his wife was deaf! 

cute story about her being a 53 year old teenager

interesting that he was motivated by email - being able to work asynchronously and be able to not have to worry if he heard people correctly (maybe we wouldn't have the same internet we had today without that motivation!)

Keynote
The State of Accessibility and axe Updates

Preety Kumar

Dylan Barrell

Some interesting facts about the (free and paid) tooling to test accessibility, stressing again empathy, shifting left, and only stopping builds on things you are sure are true positives and informing but not stopping on indeterminate. They did this by focusing on specific things then expanding. Stressing on the recent growth of the tooling, and the importance of the internet especially in the COVID pandemic world. Also more empathy building. So many people if they are unaware they know disabled people don't think about it.

https://www.deque.com/


Then some boring awards i don't care about

but a potential prize contest for next year for those interested
https://www.deque.com/axe-con/axe-prize/

Hackathon
https://www.deque.com/axe-con/axe-hackathon/

https://twitter.com/dequesystems
#axecon
 

(no subject)

Unblocking Backlog Jams with Multi-Dimensional Accessibility Audits

Dave Rupert

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

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

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

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

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

Gina Bhawalkar

Going through how making products accessible which make everyones experience better

~these experiences didn't come about to avoid being sued (compliance focused), or bolting it on at the end

Wonderful products come about because of focus on design and made accessibility a focus form the start - which leads to products which are simply better for all customers

~ if your personas don't include varying abilities you are failing to build empathy

she gets into incorporating accessibility into the design system

person quotes:

I'm curious how many of you are using personas as part of the design work at your organization. I imagine if we were in a room, we would see a lot of hands going up right now. Personas are great, they're a great tool for helping teams step into the customer's shoes. But the problem with them is I see a lot of personas that never account for the fact that within a given persona, we have people of different abilities. I'm showing you an example here of a is he season in a called an tunist Ally. Ally is negotiating for a new push. He's a white man, he's there on his telephones, talks about his goals, motivations and attitudes. But it doesn't say anything about the fact that we have people within this persona of Ali with different abilities and we need to account for that when we design. And this is really problematic that most pep so he in as don't have that. Because what happens then is by sees tend to creep in, you know, this persona of a white man negotiating a car purchase kind of per spelt waits the stereotype that men are better than negotiating than woman, for example. And that could alter the viewpoints of the team that's designing braced on the personas. This also makes it problematic when personas are used as a tool for empathy. You're not representing your customers and there are not empathizing with them. So there's different approaches for solving for this challenge. One approach I've seen is companies using accessibility personas and there's some great sets out there. Whitney and Sarah ton have a web for everyone that has pore so he naps you can adopt. Barclays has a nice set as well. These can be great if you're trying to aware awareness around accessibility in your organization. They can be useful if you're writing user stories that are specifically focussed on accessibility. They can also be really helpful if you have projects that are aimed at improving the accessibility of a product where you really want to hone on the needs of users of different access bits. And they can also be great as a launchpad for ideation. Let's start by designing for someone like Emily who has cerebral palsy. The problem with these is I often see design teams getting overwhelmed because they now have accessibility personas they need to design for as well as these business personas that have been created that are more focussed on goals, needs and observations. So for that reason, one method I'm seeing gain more traction in organizations is this idea of applying inclusive design lenses on top of your existing business or design personas. Here's how this works. You want to focus on your most important personas, and add these lenses to them. So for example, asking what if a customer in this persona has vision loss? Will the solution still work for them?

Or what if the customer in this persona has, you know, is attention limited? Will this solution still work for them? And so on and so forth. We can apply other lenses too, like hearing loss, mobility challenges, etc. So let me show you an example of how you can actually put these lenses in practice. The first thing you can do is as you're sitting there at your desk making that design decision, writing that piece of content, apply each of these lenses and ask yourself three questions for each. The first is related to he can iffiveness. If a customer in this persona is blind, will they still be able to get value from this solution? Second is around ease. Will they find the experience easy to use. And the third is around emotion. Will they feel good when they're using this experience? Is it evoking good, positive emotions? Here's an example. I have a screenshot on this slide from a consumer electronics website. This is from their homepage where they have kind of this three-panel design in their homepage. There's an area about free shipping, an all right area about extended returns and an area about flexible financing. And under each area there's a link and that reeds reads learn more. So all three links are called learn more. So by applying the lens of a person who is blind who uses a screen reader and exploring that question will people in, who are blind, find this experience easy, this might prompt us to actually revisit the this design. Because we know that when learn more links are taken out of context, for example, if a screen reader user pulls up a list of links out of context, they're just going to letter learn more, learn more, learn more, it is not actually telling them anything useful about the target of those links. So you get the idea by asking these questions, applying these lenses, it is going to cause us to question our solutions and challenge ourselves to be better. So instead we might take an approach like Aetna does on the homepage of their website. They also have a design like this where they have different panels of content but their link names are incredibly specific. For example, they have a link called types of healthcare plans. H sapping or FSA. What's the difference? And health plan perks. Very specific names. You know what you're going to get when you click on those. Now, another way you can bring those lenses in to your process is when you're actually together with your fellow designers, design teams all embrace the methodology of design critique. Maybe in your next design critique you start asking more questions of your fellow designer's solution that is they're sharing. Questions like how will this design sound if read by a screen reader is this Or will that tern you're using be understood by a non-Native English speaker

In or, hey, have you tested the color contrast of the color choices on your design? So the idea here again, challenge one another to be better and work together to create solutions that will ensure we're not excluding anyone in your customer base.



Approach accessibility as a customer experience imperative, not a compliance driven initiative.


And I'm not saying to ignore the legal benefits. Those are important and those will come from doing this work. But by framing accessibility in this way as a customer experience imperative and tying it to those customer experience efforts probably already in place in your company, you will be more successful in helping your organization move past this thinking that accessibility is the check the box exercise the thing that we have to do just about meeting standards and instead, shift that thinking and shift your methodology and approach to creating better experiences for all customers.

(no subject)

Keynote
Difference Drives Innovation & Disability Inclusion Benefits All of Us

Haben Girma

She is a lawyer from Harvard who is both deaf and blind

Key Takeaway - important accessibility feature is descriptive transcripts - for the defa blind community this is essential access - i can't see what is in the video and i can't see the captions. Descriptive transcripts should include the words, but also descriptions of what is being seen. The vast majority of videos don't have captions, and even those with captions they don't include descriptive transcripts.

Closed captions
 

"The dominant narrative here in the United States and in other places around the world is that disability is a burden on society. That narrative is incredibly harmful, I had to learn to resist that narrative and create my own narrative of what it means to be a daughter of refugees, a black woman and disabled. "

 

Ableism comes up in many ways it comes up in language; includes where disability is used as a negative. For example such and such a person is blind to reason. If someone is a hiring manager and using that kind of language I'd be concerned that they are discriminating against blind applicants and that they are carrying assumptions that there is a disconnection between blindness and ignorance. That is just one example of how ableism comes up in our language.

 

It also comes up and policies, and schools and technology. These beliefs and biases get built into our technology and we end up with technology that does not fill the needs of all people.  I faced a lot of barriers going up and then I reached the point where I decided, I'm no longer willing to put up with these barriers and tolerate these barriers. I want to do something about it.

 

--- I'm now an advocate for people with disabilities, but I was not born an advocate; it took time to reach that point. Part of the transition was shifting the narrative from seeing disability as something burdensome to seeing it as an opportunity for innovation. We need to increase awareness of how disability drives innovation and I will give an example.  --- Braille was devised by a blind teacher who wanted his students to have access to text, books, articles; lots of people know braille is a tool for blind people to have access to the written word. But how many people know that it was developed by a blind person?  --- That's one of many different examples of disabled people coming up with their own solutions to help others in our community. I'll give another example. --- Play this video please.  >> [Video] >> HABEN GIRMA: Before the pandemic traveled around speaking with students at universities and we have a video of a university in Mexico, instituto tecnologico de Sonora, and in this video I am in a gymnasium signing with the young man and he watches my hands and facial expressions as I signed him and then I hold my hands over his hands to feel his signs. He wants can't hear spoken language one can create a visual language and that's what deaf communities have done all over the world. The dominant sign language in the US is American sign language. In France, French sign language. Across the pond in the UK they have a completely different language and it makes no sense to me. They call it British sign language. ---

 

The deaf blind community is also innovative. If one can't see or create language one can create tactile sign language which is used by many deaf blind people. In the video I am using tactile sign language to communicate with him. He was a student back then, but he is now a teacher in Mexico. That is one form of communication. --- There are many other forms of communication. Next video. Another form of communication is salsa dancing. This is also before the pandemic. I'm salsa dancing at a club in New York City; I live in the San Francisco Bay area and I found many wonderful dance communities in the Bay Area. At one time the bouncer would not let me in the dance club, you can't come in, no dogs. I explained the dog with me was a service dog, a well-trained, well behaved seeing-eye dog. He kept insisting you can't come in, no dogs. I explained the American with his abilities act prohibited this combination and wherever public goes Seeing Eye dogs can go. And the manager kept saying you cannot come in. ---

 

Ableism is also connected to racism and sexism. When racist -- Not to put down a group of people -- they use ableist language among other things, such as this group is less capable, less intelligent, less emotionally able. That's ableist language. Sexists engage in similar arguments and that is harmful, problematic and we need those working on racial justice to also help end ableism and those working on gender inequality should help address ableism. And people working in disability accessibility also need to address racism and sexism. 

---

Several years ago I was part of a disability organization and I brought up the fact that many disabled people are killed by law enforcement and racism multiplied by ableism incredibly dangerous. In organizations only we don't talk about race and we do not have the time to address these issues and I did my best to explain the connections. But at that time they were not willing to address the intersection of racism and ableism, eventually left the organization. That's not unique. It comes up a lot in advocacy. And we need more people to be aware of intersectionality.

In technology a lot of people don't always remember these connections. If you are working on disability issues, remember to increase her presentation of the different groups. Make sure there is racial diversity in the work that you do, and in the data you collect for project you work on in the technology field.

---

So that is another dimension to ableism. Many other barriers I faced are due to people not taking the time to work on removing the barriers, but when I have been successful it has been because people around me have chosen to do the work to remove the barriers. Sometimes it is really difficult work; other times it is quite easy. One of my favorites was a high school teacher who approached me and asked, do you want to go surfing? At that time I did not know any blind people who surfed. I did not know a black woman who surfed but I told the teacher sure, let's give it a try and she introduced me to a program in Santa Cruz called Ride a Wave, and we did serving. Video please. 

---

In this video we have tandem surfing, which is larger board, I'm near the front of the board, the water guide is at the back of the board and he helped steer as we ride the wave. 

>> [Video]

>> HABEN GIRMA:

I love the experience of feeling the surfboard beneath my feet, the sun, the water. I started asking myself, where exactly are my limits? Can I test those limits?

---

That specific program did not do surf classes. so I asked surf schools in California, cannot take surf lessons? And they said they never heard of a blind person surfing, and another school said they had never heard of a deaf blind person. Let's find a way. 

>> [Video]

>> HABEN GIRMA:

In this video I am in Mount surfboard, beside me on a separate surfboard is instructor and he is nearby so he can help steer around the surface. 

And around the sharks. There aren't any sharks in the video but this is in California. 

---

So many people tell me, oh, this specific tool can't be made accessible or the specific activity can't be made accessible. That kind of negative thinking is limiting. If we bring more people with expertise to the conversation we can come up with a solution. 

---

Technology starts off as one's and zero's. Technology is converting these ones and zeros in technology that everyone can use, video, audio, braille, touch, maybe even smell and taste. So many possibilities. 

---

Ableism is incredibly limiting and we need to be aware of ableism and all the different ways it comes into our technology. I am going to pause here and invite Laura to come back on screen. Laura, do we have any questions?

>> LAURA: First, we are getting a lot of great comments. Thank you for talking about the intersection of this ability and racism as it relates to police, violence and murder, thank you for raising the importance of that And we have attendees from all over the world, Australia, Canada, Mexico, the UK, they all want to say hi. 

>> HABEN GIRMA:

I was nodding and appreciating that people from around the world are saying hi. Hi people from Canada, Mexico and other places. 

>> LAURA: they are all saying hi.

Also people ever inspired by you and they want to thank you for sharing your experienced in the loved your killer dance moves in the video. 

>> HABEN GIRMA:

I miss dacning so much. I haven't danced for a year and I used to dance every week. Many of my friends are from the dance communities. It is one of the things I am looking forward to when the pandemic ends and we can go back to gathering in groups. 

>> LAURA: Great, I'll give you one question from the chat related to that.

Someone asks, how has the pandemic affected the deaf blind community especially social distancing?

>> HABEN GIRMA:

Excellent question. So during the pandemic, deaf blind people and also blind people have faced increased stigma around the fear of touch. 

deaf blind people at least among my friend groups have developed safe communities of people we trust to communicate and interact with and support us and within those communities will use tactile sign language, pro tactile and make sure we have support and communication and opportunities for relaxation within those communities, and outside of those committees I want to send out a reminder to everyone, make sure you are not achieved without consent. There is still a lot of grabbing of blind people and sidewalks and in public places, supposedly to offer help but it is not helpful when it is not wanted.

---

So just a reminder, check in. It is great to want to help people but ask 

Apex. And by reading the menus I would know which of the stations. 

---

When I advocate, I help other people. If we tell ourselves it is just a small barrier, there are bigger problems to worry about, the small barriers add  up. When we take the time to adjust we build up the skill to deal with larger obstacles. The experience with the cafeteria inspired me to advocate for other people, other disabled people, and I wanted to build up the skills to advocate her instead of looking into law schools, Harvard law told me they had never had a definite student before. I told the, I've never been to Harvard Law school before. We did not know what the answers would be; however did not know all the solutions that we engaged in an interactive process to find solutions and make it work. 

---

It was a long process. People often ask me, what was the hardest part at Harvard Law school? The hardest part was ableism. Ableism keeps coming up over and over again; it is the biggest challenge I have faced and continue to face. I'll give an example of how it came up in law school. 

---

 

During the first semester, we had a networking event where we would meet with the lawyers from the Boston community so the school brought in a bunch of lawyers and there were drinks, music. I was standing at a table with my braille computer keyboard, my guide dog on the floor; across from me was my interpreter and she was typing descriptions of what she was seeing around the room. And I told her I am ready to talk to people. Let's bring over this attorney so he came over to the table. And he started, not talking to me, but only talking to the interpreter. He told interpreter, tell her she is very beautiful. It's inspiring to see her. What a smart dog! Does a dog go to class with her? And I jumped in and said, I'm deaf blind and everything you are seeing is coming into the keyboard and I am reading it in braille. It might make more sense to you about what is going on if you try typing. Do you want to try typing? That might help to understand what is happening here. 

He said, oh no, he was enjoying watching us and he told the interpreter again, only talking to the interpreter not talking to me to tell me that I was very inspiring. He was not inspired to offer me a job.

---

Often times disabled people are called "inspiring." It is a word that people cling to when they are feeling uncomfortable, awkward. If "inspiring" is used towards a positive action then it is something positive. I like it when people say I am inspired to make my website accessible. I'm inspired to try salsa dancing. 

Those are positive ways to use the word. But please don't just call disabled people "inspiring" because you are uncomfortable or awkward.

If you're feeling uncomfortable or awkward ask yourself why. Investigate that emotion. 

That is how we unearth ableism and work to address it. 

---

Incidents like that kept coming up in law school and they continue to come up, post law school. 

---

I graduated in 2013 and I  have a photo to prove it. Photo please. Silvia, do you have a photo of the graduation? The Dean is handing me my diploma and my guide dog is standing beside me wearing a fancy coat. What I did Is called image description and it provides access to blind individuals and have also described videos throughout this presentation. I hope people watching this will remember to add image descriptions to photos you share on your website, your apps, social media, same thing with videos, describe the key visual details in videos so blind people have access.

---

I graduated in 2013 and started working in a law firm and worked on cases applying the ADA to technology. There is a myth that the ADA did not apply to technology but it does; I've worked on cases and the defendants were not happy about that. It is much, much easier to choose inclusion, to choose to invest in accessibility rather than dealing with lawyers. 

---  

I'm emphasizing education and training. I want to teach people about ableism. It comes up in so many ways, intersecting with other forms of oppression such as racism and sexism. And if we can learn to address ableism we will be removing so many barriers and forms of oppression.

---

Many of you who are watching this know about the importance of accessibility; but sometimes you encounter stubborn, difficult people who don't get it. So I offer you some argument you can use to convince those stubborn, difficult people why to invest in accessibility. Argument one: you will reach more people. There are over 1 billion disabled people around the world.

Bring up the slide with the arguments. 

---

Argument 2: digital access accessibility increases content discovery; if you add captions and transcripts to your videos, image descriptions or alt text to your photos more text is associated with your content and search engine optimization.

---

Third argument: investing in a facility drives innovation. When you address a disability challenge you come up with a solution to help many people. 

In the sixties and seventies the kids in the city of Berkeley demanded access to the sidewalks and the city install curb cuts and ramps to the sidewalks so wheelchair users had increased freedom and mobility when the city installed curb cuts. 

---

Parents with strollers appreciated the curb cuts. Travelers with luggage enjoy the curb cuts. Kids with skateboards love the curb cuts an d now in 2021 autonomous cars use the curb cuts. Back in the sixties and seventies I doubt the city of Berkeley imagine autonomous robots benefiting from the curb cuts. 

---

When you come up with the challenge you come up with a solution that benefits the community and ways you can barely imagine. Those are some of the arguments you can use to convince people to invest in accessibility. If the stubborn, difficult person is still not convinced, tell them about legal requirements. And again, the ADA does apply to technology, including autonomous robots. 

---

I'm going to invite Laura to come on again let me know how everyone is doing, and if we have any questions. 

>> LAURA: We have a lot of questions if you would like me to dive into those. 

>> HABEN GIRMA:

Go for it. 

>> LAURA: so the first question I have here is asking, what new or emerging accessibility tools are you most excited about?

>> HABEN GIRMA:

>> (chuckles) 

I get that a lot. I'm actually more interested in making mainstream technology more accessible rather than new accessibility specific tools.

MainStreet apps, mainstream websites, we need those to be more accessible and that is what I am most excited about. 

>> LAURA: Great. 

Another question here. 

What do you think the biggest misunderstanding is around accessibility? With either laypeople or folks working in the accessibility space?

>> HABEN GIRMA:

Some people treat it just as a checklist and forget one critical part of accessibility. It is having disabled people, people who use specific accessibility features whether it is screen readers, captions, transcripts, actually test out using the website or app or other service. 

It would be great if more organizations increased hiring of disabled people. 

That would make sure that more accessibility services were fully accessible.

>> LAURA: Thanks. 

I have another question here. 

What is the most common frustration you encounter when you are navigating the website?

How can we make our websites better for deaf blind users?

>> HABEN GIRMA:

A problem I encounter both on mainstream websites and apps and websites and apps by disability organizations is a lack of transcripts. I need to be able to have a textbased transcript to have access to videos; videos have become super popular for expanding information, whether it is healthcare information or other kinds of information.

A lot of deaf blind people are denied access to that information because there aren't transcripts that go with those videos. So just a reminder to everyone. Add captions to videos and also add transcripts. 

>> LAURA: Great. 

Another question here. 

I've heard argued referring to inclusive design as a catalyst for innovation that benefits everyone is damaging because it erases the story about his ability and makes it about everybody. This is done to sell a disability to an organization. Do you have a perspective on this?

>> HABEN GIRMA:

What is said is absolutely true. 

Any story when it becomes all-consuming is damaging and harmful. Everything should be done in moderation; the disability community should not have a single story just like this other group should not have a single story which is damaging. We are diverse, we are many stories. Disability can drive innovation but that should not be the only way to see disability. 

>> LAURA: great point. 

Another question here. 

Do you have a technique to recharger spirits when you experience ableism?

How do you recharge yourself you can keep up the work?

>> HABEN GIRMA:

Excellent question, advocacy fatigue is something I struggle with another people struggle with that as well. I have a variety of things that I do that help me reset my spirits: Eating dessert. I have a sweet tooth. Going on walks with my dog; before the pandemic it was dancing, I used to go dancing about once a week. Those are some of the things. Talking with friends and that brings me joy. Every advocate should find something that brings them joy and make sure that is a part of their life to recharge and reset. 

>> LAURA: Another question here for you. 

What are some new skills or experiences you plan to conquer?

>> HABEN GIRMA:

(Laughing). So, hmm. 

I've just become a parent of house plants. About two years ago I got Jasmin plants out outside, and they are easy to grow and they did not make it. I'm hoping to do a better job this time and I am nervous and worried about it but I will do my best and I will do my research so that is one thing I'm working on. 

>> LAURA: someone in chat mentioned they love the plans behind you.

I'm sure you will keep up the great work.

>> HABEN GIRMA:

If anyone has recommendations for a new house plant owner please do let me know. 

>> LAURA: I have another question for you is we have a few minutes left. 

What has been the most rewarding change that you made after you engage with someone on disability rights?

>> HABEN GIRMA:

I really appreciate when people listen to my feedback about accessibility and implement it.

There have been several organizations that have started mentorship programs. So a lot of organizations talk about the importance of increasing hiring of disabled people. That is true, that is absolutely important. The next piece is making sure the workplace is a safe place for disabled people to grow and to advance. A lot of people end up leaving the organization's especially tech companies because of racism, ableism, sexism and the intersection of those three. 

---

So mentorship programs where leadership helps provide advice and invests in the success of the disabled person, is one way to address ableism  in the workplace, not the only place.

>> LAURA: Excellent. Just switching gears. What are your thoughts on accessibility overlays?

That is a hot topic now. 

>> HABEN GIRMA:

There have been a lot of adds lately regarding easy AI-based solutions to make websites accessible. Personally I have tried testing some of those and experience was absolutely terrible. So I find such claims extremely frustrating since my personal experiences with such services have been very negative. 

>> LAURA: what great accessibility project are you working on?

How is it going?

>> HABEN GIRMA:

(Lauging) Gosh, it's tricky to answer those questions. A lot of those things need to stay confidential. I do consulting with different organizations on making sure services are accessible and also making sure the story is not accidentally ableist. Ableism is ableism even if it is unintentional; and unfortunately it comes up in many projects. So it is important even if you don't think your project has ableism, to bring in someone to help review the story. And I work with artists, writers, filmmakers and people working in technology and tech-based projects on making sure there is accessibility. 

>> LAURA: we have come to the end of today's session. I want to thank you Haben again for such a great presentation and I want to thank everybody who joined us here today and I hope you have a great rest of your conference. 

>> [End of session]

ROI of Accessibility

ROI of Accessibility

Type: Breakout

Track: Organizational Success with Accessibility

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

 

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

 

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

 

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

How accessibility can help meet omnichannel goals and reduce costs.

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

 

>> Hello, everyone.  This is 

Leeann from Deque.  Thank you

for returning to the Return on

Investment of Accessibility. 

Please hang tight as we get

folks settled.

>> Hi, everyone, I'll be

moderating today's session on

Return of Investment of

Accessibility brought to you by

Greg Williams.  I'm going to

take a few -- care of a few

housekeeping items.  Today will

be hosted on demand for

registrants.  Second, slides for

today's session are available on

the website.  If you require

live sections for today's

session, you may access those on

the session page just below this

video stream.  Lastly, we'll

save the last 10 minutes of the

session for Q and A.  So please

post your questions in the Q and

A section, also located next to

this video stream.

Throughout the session you can

chat with the attendees in the

chat next to the video stream. 

You can sort messages by recent

messages, with that I'll hand it

over to Greg.  GROIG thank you

very much --

>> GREG WILLIAMS: Thank you,

welcome everybody to Axe-Con,

and this afternoon's session, I

think getting started now.

A couple Quebec things, you see

the chat you have there, some

people were talking about not

seeing it scroll.  So you might

want to switch it to most 

recent.  So you can see the

comments as they come in rather

than most popular, which is by

default, I think.

The other quick thing, just to

say I know if you haven't gotten

your book yet, some of the

things I'm going to talk about

here, a lot of it actually tunes

directly into the book that's

been discussed earlier today, so

make sure and get your book and

read through that if you haven't

had a chance to do that.

I'll go ahead and get started. 

The Return on Investment of

Accessibility.  I was listening

to the keynote speakers, and as

we talk about this, I think it

was said, ROI doesn't sound like

the right term here.  And he's

correct.  We really shouldn't

think about things in that way. 

But the business world being the

business world, we have to.  So

I may change the title on this

at some point.  More to talk

about the business case of

accessibility, because the

reality is, as you try to add

accessibility into your

organization, especially to do

the work to make it sustainable,

it's going to cost money and

time to do that.  And money and

time, when you're thinking about

being in the boardroom, just

saying it's the right thing to

do, unfortunately is not always

going to get you what you need. 

I think it should, and I think

some day it will.  But for right

now, we have to think about

these other aspects of it.  So

the information I'm going to

share with you today is going to

help you to paint that picture,

to maybe illustrate for people

who don't quite get it yet that

not only is it the right thing

to do, it's also just good

business as well.  And good

business for four main reasons

that I'm going to share with you

today.

So what are the aspects of

return on investment for

accessibility, or what are the

business cases that we can talk

about?  And as I said, there's

four main ones I want to 

discuss.  Those four will do

some seriously positive things

for your organization.

The first thing to think about

is your market share.  And we're

going to talk about market 

share, we're going to talk about

ecommerce.  We'll talk about the

disruption of COVID in 2020, and

what that meant to ecommerce and

what that meant to people who

might not have had any other

options other than the digital

storefront to be able to get the

product or service they wanted.

So we'll talk about that, we're

also going to talk about

operational costs, and this is

operational costs in the

omnichannel organization.  If

your organization has brick and

mortar storefronts and you've

got a digital presence, call

centers, we'll talk about how

shifting those costs in the

right channel are going to help

you and you can do that with

accessibility.

We are going to talk about risk

profile.  This is the lawsuits. 

And although I think this is

really a negative motivational

factor, and I put it third on

this list, in fact I should

probably put it fourth on this

list, but I put it third on

purpose because I don't think

that should be the main thing

that we pursue here, because the

value of the first two that I

talked about there, outweigh the

value of risk mitigation.  And

probably the fourth one, which

saw lining your digital presence

with your company core values

and thinking about things like

social justice, again, more

valuable to your company in the

long run, if you can get people

to think in those terms.  I've

helped dozens of companies

 

create a case, and get the 

funding they needed to produce

accessibility digital content,

so I'd love to help you as well.

     Let's talk about market

share, and e-commerce.  I've got

claim your portion of the pie. 

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

of money and a lot of people

involved.  And I'm going to talk

about the U.S. market place.  I

do have efforts to get data on

the European market.  Different

places where I'm trying to get

more information, it's a little

harder to come by there, but

there's a similar story.  And we

know there's similar situations

exist, but let's focus on the

United States.

     We know the after-tax

disposable income for 

working-age people with

disabilities is approximately 

$490 billion, just short of 

$500 billion.  And this is a

group that are likely going to

need some type of accommodation

to work with your digital

storefront.  If you have a

digital storefront that's not

accessible or you're trying to

provide services and there's not

an accessible way to procure

those services this, is the type

of share you're looking at not

servicing.

     What does 4 husband 

90 billion mean in the larger

scheme of things?  The

African-American market is 

501 billion, and the Hispanic

market is 582 billion.  A

significant amount of money out

there and people who are looking

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

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

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

 

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

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

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

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

 

 

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Another way that you can work this into your  organization.

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

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

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

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

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

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

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

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

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

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

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

>> I think the question  is --

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

  

  

  

Grid, Content Re-Ordering and Accessibility

Grid, Content Re-Ordering and Accessibility

Type: Breakout

Track: Development

Let’s review the potential accessibility problems that grid layout could cause. These issues essentially center around the concept of disconnecting the source from the visual display.

 

>> I'M a membe of the CSS working group and I try to keep accessibility in mind and

If I do not know, I try to find somebody who knows more. 

---

A lot of web developers are in the same situation, you would not call yourself and accessibility expert but you turn up at an accessibility conference you show you care and people want to make sure the work is accessible so that is where I come from with this.

I am someone who knows quite a bit about CSS and I try to know stuff about accessibility and also always trying to learn and try to figure out about the different needs people have. 

I think that is really important right now because the CSS layout systems are changing quite quickly, is happening at a great speed in web platforms and we also are getting into problems.

---

When we get into new technology we may have a problem that was not anticipated in the design. This talk is mostly me speaking my brains about these issues. I want more people to talk and think about the potential issues of a new layout so we can fix them.

---

So I have a few things. I'm going to talk about the accessibility issues raised by new layouts when what specific things we have identified as being a problem and how can we avoid them in our own work but also want to think a little bit about how the platform can evolve to help so we are not just saying don't do all of these things. What else are we doing to help?

---

So CSS Grid. One of the first things that I thought was exciting about Grid, and really what got me dragged into this whole thing long before it became available for use in browsers, the thing that I thought was exciting was that he gave us for the first time a proper separation of content and presentation. I have been doing this for a very long time and I was building websites back in the day when were trying to encourage people to move away from tables. One of the things we said over and over again was CSS that you separate your content from the presentation and that is because when you lay something out when using tables you are mixing presentational data in with your content. If you want your heading to span over a number of columns you have to put that into the HTML so you're making decisions about layout in your markup. That was how we built any sites until CSS came along.

---

If anybody was building sites back then you remember how we nested tables into table cells and we would take basically a picture of website and slice it up and jam little bits of it into different table cells and fragment all the content all over the table which made terrible for accessibility because accountant was jammed into table cells a bit like doing web design in Excel. The tables were not great.

---

What are the things you were saying was  you are separating the content from the market so we had sites like the CSS Zen Graden, and I'm showing you a screenshot here, about this set of markups, people would come along and design a stylesheet displaying it differently, 

showing people how powerful CSS was, and letting them separate these two things.

---

However layout was still kind of tied to document structure. Some things we used to talk about lot was the "Holy Grail," and in a web design context it is a three column layout, it shows off how far we have come. 

The key thing about the holy Grail is that the columns should be in any order in the markup and it was actually really quite hard to achieve.

This is an article that I've got a link to on the screen, if you go to the article you would be amazed at how much code gets written to get this three column layout and because done with floats there was no way to determine how tall they were, this was the best we could do. 

---

We had to structure the source, if you look at the article. And then even more recently -- Many of us have been using a float-based, column grid. This is an example, the original grade before they went to flex box. You basically will have to have a classic row, and then to put your items inside that row. Again, we are defining the layout in the markup. We are seeing this is a row, and these are the items in that row. Items have to pretty much stay in source order because you are using floats to lay them out and they float next to each other. 

---

This wasn't really a bad thing. The fact that we could not get too far from document structure started making an awful mess. In the early days you are not thinking about accessibility; we were thinking about how can we use something in Photoshop look the same on the screen? The fact that we could not get too far away from document structure started making too much of a mess. The only way the full group grid and flex box (indiscernible)

--  If you are trying to build an entire layout without structural positioning won't go well for you.

---

So all we had was normal flow. Normal flow was blocking and line layout, what we call the basic things that things layout on the page. So if you stick some HTML upon the web and you don't do any CSS at all you get your normal flow and you get your content flowing and logical source order.

---

To do layout with floats you have to kind of keep things but imagine flow, you can move them left and right you can't jumble it up too much.

---

And now with CSS GRid in particular we have a layer that is separate from the content and reorder those things, and do this at different breakpoints and the restriction of the layout is gone and we can do the holy Grail and switch the columns around anyway we want with just these few lines of CSS. I'm showing the CSS for the Holy Grail layout and the source code is available online and I show the link at the beginning and I will put it at the end so you can go play with these demos. You also get full height columns, something we want to have for a very long time which was impossible in the earlier version.

---

This huge limitation has gone. We have this chance to separate out the structure of the document from the layout. And that seemed pretty exciting at first read, you know. There's lots of things we can do. What about responsive design? We can move things around at different breakpoints but the thing is a technical limitation has gone. 

---

Just because you can do something doesn't mean you should, in terms of accessibility there is still a limitation because if you start moving things around in your layout away from the source, you have disconnected the expense of somebody who is for instance tabbing through the layout and they see it in a different order so we end up with a source or disconnect because the reading order of your document is your document, it has nothing to do with visual display.

---

If someone is just using screenreader and having the things read out, you are probably fine but if you are tabbing around the document or if you can see it you could have a very, very confusing experience.

---

So I have a few examples of where this can go wrong. Again all of these are online so you can tab around them yourself and see what it feels like.

---

Here is my first one. This is Grid, a very simple layout. I created grid columns and using grid template areas to create the layout and I have given each of them a different place on the grid using grid template areas, really nice, ASCII R method of doing the layout.

---

This gives me the layout and here it looks fine but I don't know this will show up to well, the video is with my slides but as you around I have number each of the car so you can see the strange order. The order of their numbers is the order they are in the source so you end up jumping around as you tab around, not a very nice way to work. 

---

We can do this another way in Grid. In that situation we would position everything using Grid template area. 

What about using something like auto placement? With Grid auto placement we create a Grid container and we get our items and we ask Grid to display them in order, in the container. And if Grid comes across that it is too big to fit it moves them onto the next slide so it keeps them nicely in order for us, unless we use Grid auto flow dense. Turn on the dense packing mode in which case it picks things up which come later in the market and places them in gaps, and this could create a very disconnected experience as you are moving around the content. 

---

And it isn't just Grid. We could also have problems with flex box. I set flex direciton row reverse which switches the items to start from the end of the flex container. But we don't want people tabbing backwards navigation which would be weird, so you can do this with flex box as well.

---

This is something I wanted you to be aware of as you start to get excited about these ideas of the new layout. 

(indiscernible)

People have said to me more than once you have shown us all this great stuff and then you say don't do it. You are showing things and snatching them away again. That is a real shame and we will talk about what we might do about that later but before we get too sad about it, how much of a problem is in reality?

---

It does turn out that in most cases the layout naturally follows source order as long as you keep in mind that while you are working. So much with accessibility, if you are thinking about it from the start it is not too bad, it's fine, you can do things. If you build your site and then somebody says now we have to make it accessible it is terrible, that is the worst thing. To keep that in mind as you go and you will tend not to have to any problems.

---

The first thing is don't forget about your document. You want to be able to load your document without CSS and it will all make sense. 

I think it could be quite easy to think well we don't need to wrap everything in rows or things in the markup; the market does not matter.

But then you lose all the information that is in your document and you lose some things which are really the basis of the web, the fact that anybody can put some HTML together and put it online and it is usable and readable and the minute you jumble up your document you moved away from that.

So make sure that you have a good document to start with. 

---

And then you should work with normal flow. So normal flow, the way that things in CSS work we do not have any layout. It will really help you if you work with it. The thing about Grid and flex box is that only the direct children become (indiscernible)

Once you have your Grid container,

And you have the hidden items you can do whatever you want with them and then he goes into normal flow, and make your life easier. 

You can only make the changes  in the container and deal with the children and everything inside, you have a heading and paragraphs they just lay themselves out and you often don't have to do much.

So working with normal flow and working with the structured document and save you an awful lot of time.

---

Imagine if doing a web design, your starting point was a jumbled mess in the corner and you have to take every single paragraph and place it; it would take a long time to lay things out so working with normal flow makes your life easier and it also ensures that the experience is relatively fluid as people are using the document.

---

Something about having a well ordered document makes creating fallbacks much easier for older browsers for things that don't support Grid. That is another way to save you a long time. I've got stuff online about this. 

---

Quite often you can use the cascade to overwrite the older layout methods and you can float some items and overwrite them with Grid. But to do the floated layout the source code is important. So keeping your document nice and ordered can make it easier to create some simple fallbacks for browsers that don't support the new layout methods that you are using so that is also quite a good reason to have a good document.

---

The next thing to worry about is just to make sure that you are not flattening your document in order to use Grid and flex box. I've already mentioned that the only direct children become Grid or flex box items. It could be quite tending to think you know I want those list items to participate in Grid layout but you can't because there is a (indiscernible) layout and maybe you don't need to list items after all. If you work with Grid layout or flex left for long you come into situations where you think my life would be easier if I remove that element, but the element has the be there, it is important, you don't want to do that. So you need to try to resist the temptation to flatten out your markup.

---

Luckily, this thing is something which is getting easier; we've already gotten some solutions for this. There's two issues when people want to flatten the markup. One is that they would like to be able to have the Grid inherited down three children so you can set up a 12 column grid on the container and placed things on that whether you direct children, or grandchildren or great-grandchildren you can still use the same columns and a lot of people would like to be able to do that and we have a solution for that, not in all browsers yet but we have the subgrade value of grid template rose and grid template columns which means your child items can inherit the grid  from their parents and this is really nice indicates the semantic structures that still use common size defined on the larger container. 

---

I've got a little example of how that works, if you have not looked at subgrades yet. Here I've got these cards. They have titles and content at the bottom. On the first card the title is two lines long which means the border underneath that element does not line up with the borders of the two next to it because they've only got titles that are one line long and that is common. We can now get things to line up the things inside cannot line up with each other because they are separate.

---

 

Here I got the cards laid out there and I made each child, each list item, I've made that a grid and given it rows. If I do not have a subgrid support (indiscernible) ahtne I use a feature query to ask the browser if it supports sub grids. And if it does we are creating a pattern of three rows and then each child I span across those three rows, said the grid template rows to subgrid and get rid of the gap and that lets me line up those headings across the three cards. So subgird is good to be really handy for things wherewithal to remove an element, that is really nice. 

---

subgrids in Firefox, you can demo them. They are in development in Chrome and the Microsoft team set last year said they were working on Grid and they will be implementing subgrid. I don't know how long that is before it lands but hopefully that will be in chrome before too long and will have Subgrid available for using our designs to solve one of the market problems that we have. 

---

Another reason that people want to flatten up that market is it you don't want a box at all and this is a situation where I mentioned at the start, you have a UL, you really just want to list items to fall in line with other things. Another way we can solve that is with the content value of display.

---

 

What display contents does, if you say display none, it hides all the elements in the children like they were never there. Display content only removes the box you apply it to. The children remain. 

---

So here is a fairly convoluted markup which I don't know why you would want to have a body demonstrate the point. I've got two items directly inside and also a UL with child items, that is my markup. That gives me something that looks like this. There is the first and the second div, next to each other because we are using flex box. And then we have the UL, the actual UL has gone into line with all the other items and it has the margin drop down and inside it has his children that they are laid out as normal list items, that is not what we wanted. We wanted one, two, and three to be next to flex item 1 and 2. 

The way we can do that is to set that UL to display contents; the box gets removed from the layout and those items get laid out as if the box was never there. 

---

 

That is really cool. 

There is a bit of a problem in that when it was first implemented in browsers, browsers implemented it a bit like display none which removes items so they have gone for assistive technology as well as anyone looking at the page visually. Nothing else in the display is supposed to behave like that. Everything else is supposed to be a visual change only. But what happened with display contents is it got implemented a bit like display non -- As it was removed it remove the UL from the (indiscernible) so you might as well not have bothered doing spike content, you might as well just flatten it out. flex box fixed the problem. A couple of days I saw where this was fixed on Chrome and it looks like it was fixed in Chrome Canary, I had a quit look around. In the future it will be a great solution, if you're relying on it, tested carefully to make sure you did not lose the information. If chrome fixed it. 

So that is underway. 

---

So those are the solutions. We have something in the pipeline to help us with the flapping markup for both situations  whether we want to keep the boxer whether we don't want to have the box, and that's pretty cool. 

---

So then we have this temptation: Fixing source problems using Grid and flex box. We see this with flex box where people use order to rearrange items. So this is a common thing. You have a navigation and you want a navigation point for penguins to come first. For whatever reason, editing the source seemed like too much work, maybe it was coming up with some dreadful CMS that you cannot play with or a templating system that no one could number how to change so you think this is fine. We do not need to touch the source. We will leave that alone and do it in the CSS with order. It is easy and tempting. We set order to -1 on that item. Then our layout looks correct, that looks correct and the class will be happy because that is in the order that they wanted the problem is of course that we end up with that weird navigation tabbing order because the tab order still following the document. That is something that we really don't want to be doing again, don't fix your source problems in CSS because it will get worse and worse. You will do it once and then something else  and you think that worked and I will just use Grid to move those things around and eventually it ends up being a total mess as a technical debt masses up. 

---  

 

When I am assessing people's style sheets for the use of order I will do a search on the stylesheet and see if they are using order because nine times out of 10 it is not good thing. There are few reasons to use order in your stylesheet.

---

We are back to age-old advice. Start with the document with a solid semantic order and I said this to people nearly 20 years ago. And if you do any of these techniques, make sure you test it and make sure you have not made a mess and test it a different breakpoints, it might be fine and mobile and someplace in between where he goes weird to make sure your testing is a different breakpoint, on the way to do that is actually quite straightforward. 

We can all take the mouse, pop it in a drawer and navigate with the keyboard. We are not jumping around. Testing with a keyboard will bring up other issues potentially as well, it is a really good thing to do. 

I spent quite a while using my keyboard after shattering my elbow. It is amazing how many sites don't do it well, it is a good idea to test.

---

This is an accessibility website. 

Gives you a visual representation.

I tried this out on one of my card demos. You can see the slide; this spidery path all over the land which is the path the tabbing is taking. You've got something wrong, it's quite nice, I like the accessibility insights demo to show people what it looks like.

---

The other thing to check and I know we talked a lot about this but we have my link about resources, do check that changing display type -- Whether to flex or display grid , Or anything else make sure is not changing how things report to accessibility devices. You should only change the visual display of things, should not stop a list from being a list but browsers sometimes get that wrong so do check that. Make sure that you have got things with their semantic meaning.

---

And if you are working with any of these new stuff lookout for problems and to report them; don't assume that it is a bug everyone knows about because we are probably going to run into bugs and those are going to be accessibility bugs so we need to report them so they can fix them.

---

That's can of all the bad news, things that you can't do or things that are problematic in the ways to solve it. I kind of really like to try and solve this problem in a better way because I think that while many sites sticking close to source order is absolute defined as long as you do that from the start.

But there are places where they are useful particular when you are talking about responsive design. Perhaps the thing that you want to prioritize is mobile which is different if you want to prioritize desktop, not always the case but sometimes it is.

---

I think we need a better way to do this disconnect scenario. The other thing is that more and more we are seeing visual layout builders. I got into lab by way of Dreamweaver back in the day, I did a lot of Dreamweaver and web standards. And when you have user tools, you stop thinking about the market quickly because you are disconnected from yourself,  all you have is your visual view of the website that looks fine you don't really think about the source. Those tools encourage the dragging around of items to make your layout. Very very hard to do that and still keep the source in mind. So that is something we all see more and more of and we can't be blaming people who want to use a visual tool for messing up the source when perhaps they don't know about it.

---

How do we solve this? Firefox change the order and they were following the visual view. The thing is, the web is basically about good defaults. I think following the visual view would be dangerous. Since the web started if you put that document on the web and onto any styling you get it readable webpage. We're used to the default being sort order and that is what you get and how things work and that seems a solid default to move away from that seems quite scary.

---

In CSS we have initial values of CSS properties and their consider carefully to make sure we don't have data loss so we don't have things managing off the side of the screen or overlapped. Again these are good defaults.

---

I think tab order following the document is another good default and it means we have to take care of our document and it depends on what is displayed on the screen and was laid out on screen readers.  It would take the approach of switching layout to visual order I think it would be very easy to start caring about document order and it would avoid having us   having to do more work to make sure the order is more sensible and browsers having to do more work in making decisions about how things should work and also finding any bugs that got introduced try to make this work.

---

Really what I think we need is a way for developers to indicate a switch to visual layout on specific components, may be a whole page sometimes but also parts of the page. If there is a part of your page which might cause reordering you could ask the browser to follow the visual layout.

---

In terms of CSS specs, it is possible that some of the special navigation work, which is a way to let people navigate with the arrow keys, and let you move around unless it is clunky. Special navigation will let you move around with the arrow keys and that is quite similar in terms of wanting to follow a visual order in the document and it is defined in CSS so maybe it is something we could work with.

---

I also had some discussion with people. Just over a year ago was our last CSS real face-to-face before everything went online and the thing I miss about those face-to-face meetings is going for coffee in the breaks and that is where we often discuss things that are not part of the meeting agenda but things that are on people's minds.

Let's say the children inside the element had noted was not important which means the developer was taking control from that point, maybe progress order layout. So you could use that attribute and then from that point down you would take control of the order and the default would be the document order so this would then be control with CSS, the actual order of things. That was sort of an idea that we had.

---

Now, I'm not a browser engineer. I'm on the CSS working group, and I've got some ideas about how this might work, but how this might work in browser design I am not sure, but we need to take this conversation in the forefront otherwise it will get forgotten and I think we need to solve this before we add new layout messes. There is already a masonry layout for the grid implemented in Firefox that has the same problems. We need to solve this problem before we lay on more and more ways to do layout that potentially cause content reordering.

---

We need to solve it before more web layout is created in these visual tools; yet these tools are incredible powerful and I know a lot of people behind the really care about this issue; I don't think that is the case that people are creating tools and completely ignoring the fact they could be causing an accessibility problem. The best thing to do is to give people hints, don't do that. You realize your document is all over the place? A lot of people won't care.

But you want to have good defaults in our visual tools.

---

But when I worked on Dreamweaver we said we wanted Dreamweaver to output standard compliant code by default so really like any visual tool, be able to output an accessible layout by default. If people really want to work hard to make a terrible then they are going to  be able to do that whatever they use but let's have our default be really good.

---

I would encourage people to talk about this. If you have any way, if you have a blog review thing is important to talk about this, join the conversation and I have posted this there. The most relevant issue on my resources, masonry layout. We do need to raise this is an issue; things get solved in the web platform because people ask for it. You come and join the conversation and if you think this is important make noise about it. 

And all of my notes if you go to that URL, you will notice.

I hope this is been useful and I will answer any questions. 

>> LIZ: We have a ton of questions. Have you implemented farm labels n Grid and can you speak to an excessively the issues?

>> Generally as long as you give them in a sensible order that is fine. I've used Grid in all sorts of layout components. In generally you are fine. It is the usual thing of making sure that things are in order. 

>> LIZ: Can Grid be used in an e-pub?

>> RACHEL ANDREW: I don't think any support this, e-books -- like browsers, they are waiting for things to support, I don't know the situation in e-pub at the moment. 

>> LIZ:  with the reverse flow be as weird in a right to left language?

>> RACHEL ANDREW: It would all swtich. 

If you say row reverse, your items would start on the left. 

Row reverse would confuse everybody else, don't do it. 

Is going to be the same issue really. 

>> LIZ: another and ordering. How do you adjust the content box ordering, for example 12345 in desktop is 12354 in mobile. 

>> RACHEL ANDREW: this is the reason we want to solve is basically.

There are reasons to do this and that is why and I get annoyed when people say we need to do this.

(indiscernible).

That is why I would like to solve this office, this is the case.

We have the technical abilities to do it.

>> LIZ: 

Definitely.

We have a mobile specific question.

With responsive design often comes the same content being presented differently on mobile and on desktop because of space. Mobile specific markup or desktop specific markup; if we remove the CSS we will essentially end up with the Duplicate content, how do we solve for this?

>> RACHEL ANDREW: 

That is a different issue where you duplicated your marker, you end up in the realm of having to hide things. 

That is a different situation, hiding stuff in a good way so that someone using a screen reader is not hitting it twice for example. That is a different issue to the reordering thing. The reordering thing is going to be an issue in that situation as well. Yeah, I think there's probably a couple of things going on there, if you have duplicate content and sure you are hiding it in a good way because I think the idea is that we have a document that we can whip the CSS off and you will be fine but that is not always the reality. 

>> LIZ: 

Thank you. Question from Sophie.

Other tips or samples to combine Grid, flex and progressive enhancement to ensure broad browser support?

>> RACHEL ANDREW: 

yeah, I've got a ton of stuff online. You can search for that. 

Really the key player in this is feature queries, I showed one of my examples asking the browser do you support the stuff?

So you can overwrite things and do a layout in flex and overwrite with Grid, so use future queries, you can start testing for things that are not supported in using them as progressive enhancement and knowing that none of this can leak to a browser that is not supported. 

>> LIZ: 

The question from Elliott. How you deal with overflow problems in Grid when input is user submitted and has a very generous max length?

>> RACHEL ANDREW: 

There's a whole bunch of stuff that is useful for overflow. Things like using the min-max function. Let's say you ideally like your content, 200 pixels, nice clean design but you want to make sure that yes if somebody comes on the CMS inputs and some enormous chunk of content is not going to overflow. Using min-max is great for that because you can set the minimum to the ideal side and the max to auto. And if something is auto it will extend to fill the space for the content. So min-max is useful. There's a whole bunch of stuff in Grid. Grid and flex box are both great and looking into content and resizing things to fit in something that does not give you the ideal layout but it is bad when things are overflowing all over the place so again min-max is a good tool to start with. 

>> LIZ: 

Question from Ronnie. 

What other tools can you mention for someone named QA like myself? I got really excited when you mentioned tabs.checker. 

>> RACHEL ANDREW: 

That has a whole bunch of useful stuff and increasingly the browsers are in the deaf tools for including things so really I think it is creating that collection of things that you know.

Instead of having that list along with other things that you might be checking, finding tools that support you. What will work best for my workflow? That is kind of really, just testing of these tools that people have got, and find the ones that work best for you but the thing is to include all in your list of things you're going to check with the same prominence as everything else. 

>> LIZ: 

Question from Ames. Are you using Poly fields or just fall back for browsers that don't support auto flow?

>> RACHEL ANDREW: 

Now we are really just talking about AI. We still need to support I 10, 11; lots of people still need to support I 10, 11 but it is going away and we have people building new sites were happy to give I10, 11 a simple layout so trying to Poly field is not going to work well. 

Is better to give the older browsers something that suits them, use all the techniques because it will perform better without. 

>> LIZ: 

We have time for maybe one more question here. 

Let's go with this one.

An excess ability thorn in my side is finding ways to do true responsive tables that work best in desktop and mobile,  some solutions suggest grid to change display but that destroys table semantics in iOS. What would you suggest a responsive tables on mobile?

>> RACHEL ANDREW: 

That is another thing I would love to be solved, the fact that again it should not be changing the semantics of the table if we changed the display so what we need to do is get that problem fixed because we should be able to turn a table, a semantic table into grid layout so we can do things in mobile. There is no reason that that should not be happening other than the fact that these things are hard to implement. But that is what we should be pushing for, to get that changed. All of the solutions are not great. We don't have many options to fix this. So really what we want to do, because you can fix it with Grid, we don't want to damage the semantics is one of those things need to fix an browser so we can do this. 

>> LIZ: 

Definitely. Awesome.

We are officially at time. Thank you so much Rachael such a great session and for joining us here at Axe-Con. Thank you everyone for attending and you should have about 10 minutes to find your next room. I hope you all enjoy the rest of Axe-Con and thanks again everyone.   

  

Accessibility Testing Coverage: Automation and Intelligent Guided Testing

Accessibility Testing Coverage: Automation and Intelligent Guided Testing

Type: Breakout

Track: Wildcard

Ever wonder how much accessibility coverage you can actually get from technology like automation and Intelligent Guided Testing? In this session, we’ll review three years of audit data to show the actual accessibility coverage percentages you can get from various technologies.

 

We have two more minutes.  I am still Noah, we have a couple of 

minutes so we will let people continue filtering in and getting settled 

here for Ms. Glenn da taking her through her session on accessibility 

testing coverage.  Excited to have everybody here.  Looking forward to 

this session.  Shout out and thanks to Angie, our captioner.  I 

appreciate you very much and really looking forward to sharing the hour 

with everybody.  

Just another minute here and we will get ready to kick off.  

One more minute and we will get started for everybody.  

 

All right.  We have 231 eastern, to we will kick off.  Hello every one, 

my name is Noah, I am with Deque.  I will be moderating this session 

today, accessibility session cover brought to you by none other than 

Ms. Glenn da.  I will just take care of a few housekeeping items.  

First, today's session is being recorded and will be hosted on demand 

registrants.  If you require live captions for today's session, you may 

access those on the session page just below the stream.  Lastly, we will 

take the last five minutes for Q&A.  I was told earlier by a fellow 

Dequer who uses a screen reader, it is a Q&A link, so just for 

navigation sake.  

>> Thank you so much.  Glad everybody is here.  Let's dive in to 

coverage.  I am Glenda, I would love it if you call me good witch, I am 

a huge fan of wicked.  Up on screen I have images from the screen wick 

ID.  I have had the great honor for working at Deque for ten years and I 

live for this.  

First, let's start with accessibility testing and time.  I really want 

you to think about if you have enough time and resources to do the 

accessibility testing you need to do, whether it is for your own company 

or whether you work in a company like I do where you're helping others, 

is there enough time to do all the things that need to be done when it 

comes to accessibility testing?  And I also want to do a thought 

experiment here, and I would love it if you threw these in to chat of 

how long does it take for you to manually test an average web page.  I 

know that is a loaded question, there is no average page.  But when you 

are testing for WCAG 2.1 A or double A, when you're at the upper level, 

that is 50 different success criteria.  I will guess at what might be 

coming in on chat if anybody is answering it, I have seen numbers or 

heard people say as low as 30 minutes.  And I have seen numbers that are 

three hours, 4 hours, six, eight and larger.  Noah, has anybody fed 

hours in or are they being quiet and shy?  

 

>> We're getting 30 minutes to 2 hours, longer than expected.  A few 

hours, couple hours.  

 

>> Right.  I miss our live audience feedback, so I appreciate that.  Now 

that we have that feedback, how quickly do those test results run?  You 

know what I think?  They start rotten before I finish the test 

sometimes, because somebody is changing the code that I'm literally 

testing.  I can't get them to freeze.  I wish I could get them to 

freeze, but also understand in this dynamic world we're living in that 

is moving at the pace of life, that those manual test results are not 

happening on static pages not changing.  So with this concept of do you 

have enough time, how long does its take, how quickly is it rotting, 

Houston, we have a problem.  And I think we all sense this.  There is 

this strong, strong desire for us to make everything accessible, and yet 

finding the right resources and using them economically and wisely super 

tough.  

So before I give you some of the news, I want you to think about 

some other things and that is what would WCAG success criteria have the 

most issues for you?  Maybe you're like me and you have been at this for 

20 years and you have tested every type under the sun, and you have a 

sense of it is this, this and this and you can spout it out.  I would 

like you to actually jot them down on paper, or throw them in the chat.  

Because I want to see if before I show you what I have discovered, if 

you had the same instinct from your experience as well.  

So now that I have had you think about that, and I'm not going to 

ask for those answers yet because I know you all are talking to each 

other and that is great, you're about to give me the feedback when we 

get here now, but there is one more critical question before I show you 

the data.  

How much can automated testing help us?  I have been in this for a 

long time.  I have been saying it myself, what I think percentage is, of 

how much automation can help.  

So on average what percentage of your issues do you think can be 

found by an automated tool like axe-core?  

Percentage of criteria, do you think it is 15, 20, 25, 50?  Are 

you one of those people that want to write in your own answer?  Awesome, 

do it.  

Because I have news, and it blew me away when I saw it for the 

first time.  It dawned on me that we're sitting on a gold mine at Deque 

because we do audits, full audits, manual audits, that also take manage 

of the axe-core rules, but are fully testing for WCAG 2.1, all the 

screen readers, whatever assistive technology we need to pull out.  I am 

sitting on big data.  And what we decided to do, we have looked at it a 

couple of different ways, is first we looked at it for everything we 

have done over a long period of time.  And then we thought, well, that 

might skew the data because we have some audits in there that are client 

comes, gets that are first audit, makes some fixes and then they get 

that second audit, then their -- yes, they have got it.  That might skew 

the results.  

So we decided to sift through the data and just pull up new 

clients that hadn't done the remediation yet.  Now here is the data.  

And I am about to show you a slide that is very data intense.  I am real 

sensitive that there are, I hope, a large number of people on this 

session right now that can't see the slide because we have an inclusive 

audience so we have some people here that shouldn't see the slide.  So I 

will take some time to describe this, but in the meantime, Noah, if you 

could put a link in to chat where our final report is of this so every 

one can relax and know you can download the report that this is coming 

from.  

 

>> I will do that right now.  

 

>> Fantastic.  Here is the high level notes I am trying to emphasize on 

the slide.  It says Deque comprehensive audits for new clients, so it 

has been restricted just to new clients that haven't done any 

remediation.  And I will have anyone that can see the screen drop to the 

bottom visual on the screen where it says the percentage of automated 

issues found across thousands of pages, and it is hundreds of thousands 

of issues that were found, is 57.38 percent.  Anybody surprised by that?  

I will tell you when I first saw the data, I was like wow.  Is that 

true?  And we dug and verified and dug and verified.  And so that's 

42.62 percent that were found manually.  I want to take a moment to tell 

you that on screen, I have the top 15 most failed success criteria by 

issue count.  Who is surprised that the number one is 17.4 contrast men 

mum, no surprise there.  The next is 4.1 POENT three value.  4.1 DOT 

one, parsing.  1.1.1, non-text content.  That is alt text, you knew it 

was coming.  Followed by focus order, keyboard, focus visible, and I was 

thrilled to see at number nine, non text content, so WCAG 2.1.  And 

number ten, use of color.  No. 11, meaningful sequence.  No. 12, labels 

or instructions.  No. 13, bypass blocks, 14 page titled and 15 language 

of page and then there are the rest.  And that was the other stunning 

moment for me is after I got over the shock of 57.38 percent were found 

immediately, OMG, automation can give us more lift than I realized.  And 

I'm not negating the importance of the manual, and I'm not throwing away 

all 50-S-C, no, no.  But what I am trying to say is that our results are 

out so quickly we have to think about how we use our time and energy.  

And then I saw the other startling thing, and that is those top 15 

success criteria I just read for you, accounted for what percentage of 

all issues?  Hello, 94.54 percent.  Jaw drop.  I hope you're having a 

similar jaw dropping experience about the data, and I hope you're ready 

to pound me with questions because I think this is a really fun 

intellectual debate.  So as we move forward on this, big data, let's 

just go to a simpler visualization and that is 94.54 issues with WCAG 

fell in to 15 success criteria.  57.38 percent were found with axe-core, 

were found with automation.  And 42.62 were found by manual testing.  

So do these big data insights ring true to you, are you ready to 

pepper me with questions and wanting to dig in?  I hope both.  I hope it 

is ringing true and I hope you do want to ask questions because that's 

how we learn more.  One of my favorite movies is Willy Wonka and the 

chocolate factory.  And there is a quote where gene wilder says we have 

so much time and so little to do.  Oh, strike that, reverse it.  And I 

really feel that way on screen, I have a fun visual of Willy Wonka from 

that video.  Where do you want to catch your bugs?  You will have an 

agile script scrum, a ship BL product and a deployed system, where do 

you want to catch your bugs?  You certainly don't want to catch them at 

the back end.  When we do accessibility testing at the end, it is a 

surprise, it is a risk and it is such a higher cost.  And then there is 

back and forth, back and forth between whoever is doing the testing and 

the people in development that doesn't expect these.  And it is just 

expensive. 

 

You know, you have experienced the cost of your 

accessibility bugs.  There is so much less expensive to fix when you're 

solving them and you're still on a white board, versus a little bit 

larger when you're solving it from a design phase.  And yes, you know, 

it is not tiny when you're solving it in a development phase, it is a 

bug, you have to fix it, but it starts getting really big when you're 

solving it at QA or after release.  It is sometimes ten to 15 times or 

more expensive.  So truly the longer it takes to discover an 

accessibility bug, the more it will cost your organization to fix it.  

So really compelling for why we need to shift our accessibility testing 

in to the earlier phases so that we're not catching the accessibility 

problems between oh, I am ready to ship in an hour, or worse, I am 

deployed, to back at least in to the development life cycle.  

Now, these are not the only places you can shift left.  You can 

shift in to your design, you can shift in to your product backlog, but 

right now I will focus in what we can do in that dev cycle, which is 

proactive accessibility testing at the development stage by your really 

smart developers who do like to get things right.

 

 

So speaking of get it right the first time, there is a tool that I 

want to make sure everybody knows about, and it is called axe dev tools.  

On the left of the screen I have proactive axe dev tools, and a picture 

with a shirt I'm wearing that is curly bracket, friends don't let 

friends ship inaccessible code.  Do you know why?  Because developers 

really prefer not no have tickets coming back.  We want to get it right 

the first time.  Versus what so many of us have to experience is the 

more reactive far right testing that feels a little bit like a cartoon 

situation, where you're caught on a treadmill going faster than you can 

even keep up with.  And I do have a little image here from a very old 

cartoon from when I was a child, a George jet son running on the 

dog-walking treadmill and his dog astro is watching and George is saying 

Jane, help, stop this thing.  Because any of us that have lived that 

reactive test, we certainly do want to get off that treadmill.  

So what I would like to introduce you to right now is axe dev tools.  

Some of you may have already experienced axe dev tools, awesome if 

you're ahead of the game.  If you haven't, it is a form of intelligent 

guided tests specifically designed for developers.  And I want to pose 

this question.  The first time I saw these stats I said prove it, prove 

it to me because I don't believe it until I see it with my own eyes.  

Developers with intelligent guided testing, I-G-T, really are finding 

anywhere from 72 to 83 percent of the WCAG issues without being formerly 

trained in accessibility.  It is profound.  Now, those numbers may seem 

like Glenda, what?  I want you to remember that axe KOR is accounting 

for 50 percent.  So we running that, getting 58 percent, and now let me 

show you the intelligent guided testing concept.  

Remembering that the top 15 success criteria, I will just read 

through them quickly by criteria name only, are in order, one, contrast 

minimum, two, name role value, three, info and relationships.  Four, 

parsing.  Five, non-text content.  

No. 6, focus order.  

No. 7, keyboard. .  Eight, focus visible. .  Nine, non text 

contrast.  Ten, use of color.  11, meaningful sequence.  12, labels of 

instructions.  13, bypass blocks.  14 page titled, 15 language of page.  

What can we do to empower our developers?  Anybody curious or wish I 

would stop talking about contrast?  I often look at contrast numbers, 

color contrast 1.4.3 on text and it is big and it can often be solved in 

one place.  So as a thought experiment I thought what if I take this 

data and I drop it.  Let's assume we will fix it, it will get fixed up 

in the C-S-S and it is just gone, solved.  Gang, we're still looking at 

46.31 percent of all of your issues being found automatically and even 

if we dropped 4.1.3, because we solved it, these other account for 

92.2 percent of all the issues you will find if you're like my 

customers.  And I have looked at this deeply with medium size, large, 

small, gigantic and these hold true.  Is it the exact percentage?  No.  

Is it in the ballpark, neighborhood?  Yes, it really is.  

So let me introduce you to intelligent guided testing. 

 

It is a 

powerful new feature the axe dev tools.  Intelligence guided testing for 

developers is, I believe, 18 months old.  Went through a wonderful beta.  

It is completely designed for the developer who is smart, wants to do 

the right thing, and is not an accessibility expert.  What does it focus 

on today?  Today the areas that we have to support for are page 

information, page title and language, headings, lists and images.  

Buttons and links.  Keyboard testing.  Hey, we're getting complex here.  

Modals and focus management?  Wow.  And forms, labels, error messages 

and required fields.  That's some of or a lot of those top 15.  

So if you never experienced axe dev tools before, you can sign up 

for it right now.  There is a free trial, 14 weeks.  You can download it 

today.  Once you get it downloaded, if you're already an axe extension 

user, then you will be used to opening up P inspector, opening up axe 

dev tools and you'll still be able to run the axe core rules to get your 

failures at a critical serious moderate or minor level, to get your 

review issues, but you will see when you get the upgrade to dev tools, 

that there will be an option for guided tests.  And this is where we can 

start lifting developers to get it right the first time without becoming 

tenured experienced accessibility experts too.  

So if you open the guided tests, the areas that will begin to 

populate will be some panels.  And the very first one will be keyboard 

and modal and page information, and they're like wizards.  How many of 

you are in the United States and started working on your taxes?  It 

reminds me of the wonderful tax wizards that help step me through my own 

taxes which are complex to fill out, but you can guide me with well 

designed questions.  

 

 

Let me show you a couple of these panels.  The first one is so 

simple.  I have gone in to the page information one and I pulled up on 

the left a site that is called our awesome recipes site.  It is a 

purposefully inaccessible site that was created for testing purposes, 

thank you.  And within axe dev tools it asks a simple question.  It says 

to me, Glenda, this awesome recipe site with a recipe dashboard, the 

page title is, quote, bracket, insert title here.  Does that accurately 

describe the purpose of the page?  And there's radio buttons, yes, no.  

Easy to answer.  This is something the developers can get right the 

first time.  On keyboard, this one is very powerful.  Open it up and it 

will run automatedly through the page counting and marking the tab 

stops.  I have run it on this awesome recipes page.  It is just 

finished.  I have a result of auto tab successful, 19 tab stops were 

recorded click next to continue.  And it is then going to ask me to you 

see a tab stop where you know developer there is supposed to be 

interactivity?  And if not it will let you pick and show where they are, 

and before you know it minutes later you have finished keyboard testing 

and maybe prevented an accessibility issue from ever making it out of 

development.  A couple other examples, modals, it comes in and says is 

there a trigger for the modal?  And it then checks to make sure that 

once the modal is open, the key control stays inside the modal and 

doesn't fall back out.  And then it asks if there's a trigger to close, 

and then once you close it, it shows you where it is landing and it says 

is this the right place?  Did it return to the right place?  Which is 

developer can fix before it leaves their fingertips.  

 

 

What I would like to do is let me see if I can open this up, so instead 

of screen shots, we can see if we do it live.  Noah, I want you to watch 

chat for me.  If I am not audio describing enough what I am doing, you 

attendees out there hold me to that high standard and please interrupt 

me.  

 

So I opened up a site.  I am in axe dev tools, I have run my first 

scan, it has found 33 total issues, 21 of them are for review.  Because 

I am aware of this site, I am going to go look at just those 21 issues 

and review them so that I can get them out of the way, because those are 

worth reviewing.  And down in the dev tools, it is in the axe dev tools, 

I am inside the inspector and I am in chrome, there is a section that 

says the potential issues need your review, and please save your results 

to review.  So I will press a link that says save results.  It will name 

my test the lovely title of my page, insert title here.  I will save it.  

And I will go back to reviewing those issues, and I will highlight, 

there is an option, I click on the 21 review issues link, I click on the 

highlight option, and sure enough I get a highlight to the section of 

the page where it is now telling me, you know what, there could be a 

color contrast issue there.  And because there is some foreground 

background imagery going on, we're not for sure that automation can 

figure this out. 

 

I now have an option to manually review this and say, 

yes, this is an issue, or no, this is not.  

So I am going to click through and visually look at these 21 

issues, checking if all of this content is visible at a strong enough 

contrast for anybody seeing me do this, the contrast is so strong that I 

didn't even need to pull out any testing or look, it is practically 

black on white.  And so I went ahead and did that.  

Once I am through there, and I didn't have to do that piece, I 

could have gone straight to the guided test.  Here is one of those 

guided tests in live action.  

So if I go and do the simplest test of page information, there is 

a panel that says page information, guided test, not started, zero 

issues found with a link that says start testing page information.  I 

click on it, it says let's get started.  

Is your page in the right state?  Yes, page is the way I want it 

to look before I start.  I press the start, here is what I have given 

you a screen shot of.  The page title is insert title here, does that 

accurately describe the purpose of the page?  No, that does not.  

This is my awesome recipe site for chocolate cake and spaghetti and 

grilled cheese.  So instead of automation running, saying there is a 

language attribute, it is the human being going and this is English and 

that's what the majority of the page is.  Say next.  I now have a 

detailed issue that has been written that has code snippets, how to 

solve, finish, and I spent one minute and I was chitchatting.  Each one 

of these modules have that simple walk through.  I would like to show 

you one more. Ly go no aria modal, because I think it is super cool that 

the axe dev tools team took this one on.  

We the help developers understand this simple test.  So I have 

opened up the intelligent guided test.  Before you hit start, I will 

make sure I put my site in the state I wish, I am good, I am on the 

right page.  It asks me a question, does the modal you would like to 

test have a button which launches it?  Yes.  My modal has a launcher, I 

am familiar with the site.  The page or the modal I will click open is 

the cook chocolate cake, but it is just asking here is there a launcher?  

I say yes.

 

 Now it says please select the launcher that triggers the 

modal you would like to test.  And so I come over here and actually 

click on the cook chocolate cake area, it is in a span on the page.  And 

I click next.  And intelligent guided test triggered the modal, because 

I told it where the trigger was, and then it ran a little test and then 

it says click next to continue.  It is now making sure that focus stays 

within the modal, tells me to click next.  Asks me a simple question, 

can this modal be dismissed or closed?  Yes, it can.  I say next.  It 

dismisses, tries to close, and I see that it is highlighting the whole 

scrolled area of the page as where it is landed back.  And now the 

highlights all the way up here, the whole page.  And it is like, hey, is 

that where I was supposed to go when it was dismissed or closed?  No, 

no.  So the return was not there.  And then it wrote the error for me.  

When the modal is closed, the focus is not returned to the triggering 

element.  Finished.  I finished testing that modal in two minutes on top 

of chitchatting.  

So I have given you two live examples of that.  I will shift back 

to my presentation, encouraging you to sign up for axe dev tool two-week 

free trial.  And let you know that what I have shown you here, is really 

just the beginning.  Because we will not rest until we can make more 

progress in having things be born accessible, empowering developers and 

designers to do the work right without ten years of accessibility 

experience.  We want to help people succeed so you will see more 

intelligence guided tests coming.  So I want you to commit to shift 

left, recognizing that you can save time and money and I swear, I swear, 

you can have your developers with intelligent guided testing literally 

find anywhere from 72 to 83 percent of your accessibility defects during 

development.  I am not kidding, it is true.  Does that mean manually 

testing experts like me will cease to exist and get old and dusty? 

  

   No, 

think we will still be here, but I would like to have you get that 

fixed, no the stuff at the 68 percent that we can fix at the developer 

level.  So I want to ask, are you ready to step in Willy Wonka's 

elevator with me.  I am showing you where they have just stepped in.  

They're a little nervous.  Why am I asking you to step in here with me?  

We need to break through this imaginary glass ceiling we put above our 

heads.  We need to think different, we need to not just do it the same 

old way.  Think sideways, think inside out, think upside down, just like 

the VA T O.R..  because we really can make our accessibility dreams come 

true.  I believe it, and we owe it to all the people that came before us 

that built the foundation that our careers are currently built on.  So 

let's make a better future.  Time for questions.  

Noah, does anybody have any questions?  

  

  

 

>> Oh, Glenda, what an active awesome bunch.  I have been fervently 

trying to answer as many questions as I can.  What a great bunch of 

people.  Glenda, awesome presentation as always.  

There were some questions I didn't answer because I wanted you to 

weigh on.  How long does it typically take for accessibility testing if 

you're doing a manual comprehensive audit?  And in your estimation how 

might a tool like I-G-T-E impact that time?  

 

>> So that's something we're experimenting on now.  What I would say is 

if we're looking at full comprehensive, all 50 success criteria for WCAG 

2.1 and who knows what 2.2 will end up adding, right now we're looking 

at the efficiencies and moving the intelligent guided testing tool in 

there for our experts, but I will tell you that our primary goal at this 

moment is not to make it easier for the experts, but to make it easier 

for the innocent and intelligent developers so we can stop this further 

left.  So I don't have the data yet.  But I believe, here is what I 

believe.  I run experiments all the time.  If a person tests a 

relatively complex page as in your average web page out there and they 

spent less than two hours on it, I think they have a section they're 

missing.  And if they spent eight hours -- we can spend all day there.  

We can spend all day there.  So I hope, I hope that this will move in to 

the accessibility expert field, but our first focus is let's get the 

developers to do it.  So it is not designed for me ideally yet.  

 

>> Yes, I agree.  Just for my own experience of talking in the field, it 

is exactly how the discussions go.  Right now it is about that shift 

left and using it upstream.  When you talk about efficiency gained 

within a depth process, it is 80 percent of your tickets, you don't have 

to write all the tickets.  It takes testing, but it still takes time.  

 

>> I will say one more thing.  It is hard become accessibility expert 

inside a company that cares passionately about this and to recognize, I 

am not their primary user target.  It is that developer.  So it is 

really important that we not pollute the design to solve my needs, but 

that we design it for the developer so we can get that max lift at that 

level.  And I'm a secondary customer.  Accessibility experts are a 

secondary customer.  We are still working on it, fun question, I could 

talk about it all day.  

 

>> You and me both.  There was an another question that I thought was 

interesting.  There was a lot of data behind the research, and I tried 

to answer questions on the coverage we port because there is a lot of 

break down op how we source the data and what sort of applications, but 

there was a question about did we look at sort of bucketing the 

applications of websites by specific types, like read heavy applications 

and how that might affect the data?  Did we slice or dice the data?  

 

>> We did, we did slice and dice.  It was hilarious how little it 

changed things.  I think the only one that had like a significant change 

was some E-D-U sites.  So we did slice it and it was so nonuseful that 

we didn't include it in the report.  

 

>> Interesting.  In a certain way, that was very hardening, so general, 

that we really did get a good global view on that.  

 

 

 

>> It is very broad spectrum.  And what is fascinating about our client 

base is how, diverse of client base it is.  One day I will talk to 

somebody heavy on interactive games, and another day somebody that is 

financial.  It runs the whole gamut.  

 

>> There are a lot of questions if we will have similar tools for native 

mobile environments?  

 

>> And you know what, Noah, we need to answer that question after the 

fact.  Can you find a way for us to answer that to whoever asked it, 

because I don't know the answer but of course we want to.  And I don't 

want to guess.  

 

>> Totally agree.  For everybody's awareness all the Q&A will be 

archived and captured so we will reply where we can.  Like you said, it 

is the kind of thing that we are doing research on and stuff, but beyond 

that, there is not much more I can say.  

There are some questions about kind of comparing and contrasting tools, 

like the axe tool and the intelligence guided tools to some of the other 

awesome free accessible tools like wave and accessibility insight.  Do 

you have any general comments on how these things compare?  

 

  >> So what I have experienced is I haven't seen true intelligence guided 

testing in wave.  I see good automatic coverage in waive but not I-G-T.  

And the accessibility insights we have looked deeply at, and there were 

some pieces that have some similarities, but -- and I am a purist.  I 

have been doing this for 20 years, I come from an E-D-U background.  I 

think it is in the vein of this but it is not as advanced in how much it 

helps and lift as well as very focused on developers getting through 

quickly and accurately.  

 

 

 

>> Agree.  Another question here, and I love how specific this question 

is.  From nick the geek, one of the biggest issues that come up is 

minimum contrast and one of the more difficult issues to test is text 

over variable background like images and gradients.  Are there plans to 

add testing to this for dev tools?  

 

>> So I do think that anything, anything that is up in those high 

coverage areas, those top 16 things in our criteria are in our space 

now.  Not to say those are the only 15 we're looking at, because we're 

also looking at things that even though it might not be something we can 

automate, we can certainly guide you through it.  And let me give you an 

example.  

Testing multi media for captions and audio descriptions is not 

something we can automate fully at this point, or I haven't figured it 

out.  But KA mar is working right now on intelligence guided testing for 

that topic.  So yes, we want to cover the gamut.  

 

>> Yes, as much as possible.  That makes sense.  We have five minutes 

left in our session so we will keep cruising through these.  

This is actually kind of related to what I think you just said.  

Is there a way to use the axe tool to test web and media in the browser, 

or only content on the page?  

 

>> There will be.  I was just talking about it last night.  I don't know 

what her release is on it, and I don't know if that was news I was not 

supposed to share because we she will talk about that later.  I don't 

know if you noticed, but she gets pretty passionate.  She is like a 

freight train, so I anticipate you will see that one pop up sooner 

rather than later.  

 

>> Yes, exciting stuff on that.  Somebody asked, I would like to 

contribute my data team and experiments on testing medical solutions 

like electronic health records an patient health records.  Do you have 

any advice for anything like that?  

 

  

 

>> So I think that the intelligence guided tests in dev tools, 

especially if you have a web interface you want to run this on, I think 

you can have competitions and have work sessions with your developers.  

And have them hack and see what is the fastest way for them to get 

through.  And when we did these things, we had experiments, the first 

was named pretty experiment.  We named them after whoever came up with 

it.  And that competition inspires people to think differently about 

making this work more doable.  And know this, as your developers go 

through this, there was one interesting thing I discovered.  Remember 

when I showed you the page information screen where it asks those two 

simple questions of is this an appropriate title and is this appropriate 

language?  Well, I can finish that testing so quickly, reliably, that my 

results at the end are the amount of time that I spent with 0 minutes 

and that makes me mad.  I am like, hey, I spent 30 whole seconds in 

there and I finished a section.  Small things like that.  What drives 

the developer, what makes it sticky, what makes them want to do this and 

be successful.  So I would run hack days and experiment days.  

 

>> Interesting.  Sounds like fun.  Several questions along this line, is 

Deque doing sort of analogous research with our native mobile sets and 

tools?  Is that something we're actively working on?  

 

>> It is, I just only have so much room in my brain so I don't have that 

data in it, but yes, we have a dedicated team working on that.  I just 

don't have the knowledge right now to tell them that.  

 

>> And I will make sure to communicate that out to people, that we're 

working on it, we want those numbers as much as the HTML but we just 

happened to get the web stuff first.  

 

>> Yep.  

 

>> I tried to answer as many of these as I could on the fly.  

 

>> I want to ask people, do you feel that this data is compelling and 

that the way we have been talking about automated issues where we're 

only counting S-C, like which S-C were addressed as to posed to truly 

counting the impact of the number of percentage of issues that are found 

automated to manual.  Is this compelling to you or are you like, yeah, 

whatever Glenda?  

Because it made my day and I want to know if it made yours.  And I know 

there is a 22 second delay.  

 

>> There is a 22 second delay, so we will see how it goes on the chat.  

We are at the hour.  I will watch this as we wrap up.  But just to keep 

everybody as close to schedule as possible, so thank you Glenda for 

obviously sharing your time with us in this awesome research and great 

session.  Thank you to everybody for attending.  Really blown away at 

the level of engagement and questions.  Please enjoy the rest of your 

axe con.  Thank you and have a great rest of your day.  

 

>> Bye.  Thank you.  

 

Applied Accessibility: Practical Tips for Building More Accessible Front-Ends

Applied Accessibility: Practical Tips for Building More Accessible Front-Ends

GCal

Outlook

• Type: Breakout
• Track: Development

 

As front-end developers, we are tasked with building the front end of a Web site or application‚ in other words, we are building the user’s end of an interface. This is why it is crucial that we ensure that the front-end foundations that we build are as inclusive of and accessible to as many users as possible. To do that, we must build with accessibility in mind from the get-go. This, in turn, means that the way we approach writing HTML, CSS, SVG and JavaScript *might* need to change as we take into consideration many factors that affect how (in)accessible our UIs are.

This talk is a practical one, chock-full of tips for creating more accessible front-end foundations. If writing HTML, CSS, SVG and JavaScript is part of your job, then this talk is for you.

In this session — a series of macro case studies from real client projects — Sara shares some frustrations, many lessons learned, and a lot of practical tips and tricks for building accessible front-end foundations that you can take and apply in your own projects right away.


MISSED START
 

practical. 

>> Because this is a recipe application also the time I going to have their hands busy or dirty when they were using it so we wanted to create a way you could navigate the application without actually having to touch a computer and get dirty so what we did was implemented voice navigation and let me show you how this works. You can click the little button here and watch as I talk and the application will navigate between sections. 

--- Go to cupcakes. 

---

Vanilla cupcakes. 

---

Recipe. 

---

So you can see how that creates the ability for us to navigate the application without ever having to touch our computer.

We can also use other hardware like the lead motion device which allows it to use gestural input when navigating our computer so I can input the device and it instantly recognizes it. We are using CSS's regions to breakout the content into different slides and instead of having to test the device to navigate we are actually using the lead emotions and you can use gestures to actually swipe to the content and continue cooking. 

Another thing we can do is add more features to our application like a timer that allows us to count down how many men's we have left when cooking our cupcakes or adjust the quantity for example if you wanted 20 instead of 12 cupcakes I know exactly how many tablespoons of unsalted butter I need. 

---

A great feature and challenge other web is that it fits on every screen so we really need to make our content responsive. 

>> The application was built with user in mind and that is what made it so feature-rich and so practical.

To date I still remember how incredibly inspired I was when I watched the video; I was fascinated by the possibilities of what I could do and create using web technologies. But the idea that I had the ability to use tools that we have at our disposal to design and build solutions that serve people and make their lives better.

---

CJ could have created this application using cool, modern CSS features without adding the voice enhance support for the experience would not have been as inclusive or as practical but by doing so he created a more inclusive experience, a more human experience and above all a more memorable experience, one from which I still draw inspiration a little less after 10 years  after its creation and by the way navigating a webpage using voice commands is actually more common than we think. Sometimes it is even the necessity for some users. I will touch more on that later during the talk.

---

Unfortunately today thinking about people means context,  disabilities and preferences to creating experiences that work for everyone often sounds like a burden and a creativity killer but this application is living proof that this does not have to be the case. Oftentimes constrain fuels creativity.  I really like the way that Microsoft expresses it on the inclusive design reference,  a great resource created by Microsoft to encourage and push inclusive design is a push to creating a experiences on the web.  It says expanding interactions to become more inclusive and seeing diversity differently as a dynamic inspiration for creative.

---

In order to design inclusive experiences we need to determine how our user uses interfaces and how users navigate the web. The cupcake app was an example of a context where the user would have difficult touching the screen with user hands and people could be browsing the web  in a different context that affects the ability to use interfaces and some people are born with permanent disabilities that fundamentally change the way they perceive the world and other people might be browsing the web with a temporary's ability caused by an accident.

---

As with everything the more you do it the more efficient you get a doing it and the less of an effort and takes. In this talk I want to share some tips that are small and fairly easy to implement but can have a big impact on accessibility and inclusivity of your products.

---

The good news is that you can cover a lot of ground and create far more resilient   and inclusive accessibility experience by starting with a solid foundation and the foundation of every accessible website is semantic HTML.

---

Semantic HTML is the universal language that only devices accessing the Internet understand, including but not limited to browsers, reading absent screen readers. 

---

Each HTML element describes the type of content that it presents and using semantic HTML and using the correct HTML elements for the correct purpose is much as possible. If you have a heading use a heading element; if you have a paragraph you say p tag. Using the correct elements your country can have structure and meaning,

And you can quickly scan it and they can get a clear idea of which content is the main content, , Which content is complementary heading, section blocks and white space are used to indicate importance. The user can get a clear skeleton of the page just by looking at it but a visually impaired user cannot. They will often rely on screen reading software to convey content structure and meaning and screen readers rely on an HTML semantics to create an allegation that the user can use to navigate more efficiently.

---

In this talk I am demoing how and screen reader uses, this increases and facilitate the beginning so the web.

---

You have headings menu that allows you to jump to a particular page. It lists all the headings on the patient allows you to choose which one you want to jump to and in addition you have other menus.

You have the header, navigation, search, main ,etc.

---

And you have the list menu which contains elements on the page.  There's also the forms control menu which contains all the form controls on the page so that the user can also navigate and jump to them.

---

If the using is using semantic markup and proper sectioning elements,  the user can move from one area of the page to another without having to go to the content in each section. And it is very important for them to be able to do so. But the document structure is defined by the document structure in your HTML so if you don't provide heading the document hierarchy for screen readers will be affected. 

If you do not use a land market will not show up in the router and the user will not have the ability to jump to it.

This sounds pretty straightforward. HTML 5 provide sectioning elements and levels that are used to define the document structure similar to the visual hierarchy that users can get. Use these elements and you should be good to go but things are not always as simple as a sound. But if the design specs as they do not have a heading somewhere in the user has to infrastructures for visual elements for example, in a product I worked last year we had a couple of interesting scenarios.

---

I had a couple of places without headings associate with the midsection of the page, page listing a series of articles like this one had a description of top four sighted users and the list of articles and the sighted users can tell what the articles are about and how they relate to each other using the description of the content in the header.

---

I built a basic structure of the page but when I navigated the page using the router, I noticed two problems.

The headings problem including the list of all the headings with no context starting with a heading level 2 skipping to heading level 1. , There is no clear correlation between these headings that they belong to a specific section or title because the title is missing. And navigating using the landmark menu and this was in chrome I got all the main landmarks looking good except for the main content area.

---

We will need to read the entire paragraph before it announces that this is the main section. The fix in this case was simple: both medications were broken because the main section was missing a heading and since the design had no visible heading I added heading only exposed to screen readers and we will talk about hiding content in the next section but for now suffice it to say that this applies styles that highs this piece of text visually on making sure that is accessible by screen readers and adding these heading fixes both the headings and the landmarks menus in the rotor. 

---

Adding a title to sections where one was missing was straightforward but then there were also instances where it looked like there was no heading but in reality there was one. 

---

Similar to the other templates that also slightly different with the tag in category page templates. We had a header at the top,  paragraph at the beginning of the page and then content in the sidebar and the main area containing a list of articles or resources sharing the same tag or category. 

---

Looking at the design are visually divided the elements on the page into three parts. 

Because I was familiar with how screening reader users navigate the page and because I made it a habit to always think about this from the semantics perspective I knew that navigating the page with the rotor using landmarks and headings something weird was going to happen and it is because of the little park here and heading inside of it.

If a user is navigating user headings this heading which open the headings list as resources tag with -- Incomplete. Tagge with what? Answering the question provided me with the first step to solve this. 

---

Now that I have a complete heading was well what is this heading for? Heading creative petition the content will follow it but in this case it was not content, not on the sidebar. This heading describes the content on the right, in the main section and describes a list of articles these articles on the right are all the resources tagged generated. It should be part of this main section of the pace and since it is the main title of the page it should be marked up as such meeting should be a level I heading even if it is visually styled to look smaller like it H2 or H3. 

---

With all that taking into consideration I visually separated the heading from the sidebar and the resulting markup looked something like this.

Somewhere in the code -- If I remember correctly --  Due to layout requirements are placed heading outside the main elements so I needed to let the screen readers know that the headings exist elsewhere. (indiscernible) -- The first paragraph, and now the page displays my landmarks properly and the screenreader associates a heading  without landmark and the heading displays the proper structure and hierarchy to demonstrate the relationship between all the articles in the min area and categorizes under the generative tab. 

---

Taking that into account and writing the underlying code the markup would've been much more different  and much less accessible so the main takeaways are use HTML 5 landmarks, provide headings were needed,  don't skip headings and if it looks small use the appropriate heading level in the HTML and make it smaller using CSS. 

If it is visually hidden provide one for screen reader users. 

---

80% of responders of screen readers will use regions navigate the can only do so you choose to use them instead of wrapping everything in this. You do not you semantic HTML elements you take away the user's ability to navigate the content, making it frustrating and accessible. 

---

We mentioned earlier that the rotor contains many different menus, one for headings,  landmarks and more and among them is it links menu and informed control menu and knowing how a screen reader user might advocate a page opens up the opportunity to improve the user experienced even more.

---

A common design in e-commerce websites is displaying  a list of products on the page, each with its own add to cart button. 

To demonstrate here is the Chilly's website using little bottles. Each bottle comes with its own ad to cart button and view link if you want to learn more about each bottle. 

You get a list of all the form controls on the page including the add to cart buttons.

---

Quickly scanning these buttons you can tell that they provide very little value as there is no way to tell which product each button corresponds to.  How do I know which button I want to go to and press if I do not know which product corresponds to? I do not want to add product to the cart that I don't want. 

I bet you already guessed one way to improve the navigation, by adding screenreader only text. The solution could look something like this: you would add the product name in the middle of the button text so it says "add this particular bottle to cart." To include the product name and a button text string  sonata form control menu displays the list of buttons and each button clearly indicates which bottle it is referring to and this is a very good solution for a screenreader  using form controls but you do not want to do this because even though it improves the experience for some screenreader users  it excludes users of other accessibility technologies and makes them unavailable to them. 

---

A popular example of voice recognition software used to browse the web is Dragon NaturallySpeaking, software that allows you to use your computer and browse the web using voice commands. Such software is useful for a lot of people including but not limited to people with disabilities who can't use her hands for example power users that want to do things faster because voice dictation is faster than typing. Seeing in action gives you an idea of how it is used and how to improve our interface. 

---

Level access to created a video demoing this, and I wish you could find it on YouTube. When the narrator is saying go to sleep and wake up he is pausing Dragon and reactivating it by telling it to sleep and wake up. 

>> [Video]

>> Click full name. 

Thomas Logan. 

Press tab.

Go to sleep. 

My work email address. 

Click radio button. 

One. 

Click check box. 

Pres tab, press tab. 

Go to sleep. 

When Dragon is an dictation mode I am able to speak any type of text and it will try to translate as best as it can. Wake up. 

 

 

---

Please let me know when the North Carolina T-shirt becomes available. Period. 

Press tab. 

Now I've given focus to a custom control, and I can control this with a keyboard or a mouse and I will show you how all three options work. 

(Video is captioned).

click next state, click previous state, Press right, press right. 

Mouse grid. 

nine. 

One. 

Four. 

Six. 

Six. 

Click. 

Go to sleep. Now you can see from those three options, the best option is having a nice name, using keyboard commands is a nice way to able to perform functions that do not have a logical speech command. 

Lastly the mouse grid was used to demonstrate to you all how people have to use this technology to interact with software that has not been made accessible.

>> When a Dragon user wants to this is one of many reasons why visual labels are important in user interfaces so when we have a series of add to cart buttons, this is why adding text makes it inaccessible. The user will be telling Dragon to interact the button with a label that is different than what appears to be. But we can insert the product name into the button label, we can fix this experience for some people and breaking it up for other groups and challenges like this makes you scratch your head and think of alternative solutions and I like that. 

---

As it turns out there is a middle ground here. We can still add the pregnant the button, improving the screen reader user experience without breaking the visible name of the button by appending it to the end of the button's name, instead of inserting in the middle. 

---

By appending the text to the end the visible name is left intact and the rotor menu shows a list of the add to cart buttons; for voice control users when they say click add to cart, Dragon will label the buttons that start with add to cart, and label them with numbers like we saw in the video and then the user can speak out the number of the button that they want to clip. This works because voice commands works by saying the name of the input they want to interact with his lungs name is not broken in the markup. 

A good rule of thumb is whenever adding additional information to a label it must come after what is visually present. 

---

Knowing how voice control users navigate the web can also inspire more visual improvements or components. If a user needs to see a visible label to directly control, what about controls that do not have any visible labels? What about components that have less control such as dot navigation that we see in sliders? 

--- Is the user wants to interact with these dot navigators, they are left with two other ways, voice commands to top of the control or the mouse grid which is the most hideous and least favorable option. The most attractive one is to add level controls but he that is not process is to show table and focus .

This image is a testimonial slider, in order to make the.navigation a little more accessible I added visible labels which are opposite to look at when the dots received keyboard focus, something similar to this.

---

Other visual elements that will be more accessible and associated with a visible label are icons or icon buttons to be more specific.  Similar to the.navigation buttons if you cannot add a visible label (indiscernible) try to use I consider universally understandable other voice control users will have a hard time operating it.

---

And speaking of icon buttons I want to go deeper into other aspects of making it accessible. 

I can buttons are great example to show different ways that we can process solution and will cover the different ways to hide and expose content while making sure it remains accessible to screen readers; knowing how to show in high counter with accessibility in mind is a fundamental piece of knowledge building accessible user interfaces but first you can inspect how a button or any other element will be exposed to a stranger using the browser's tools. 

Here there's a simple button showing how it a deaf tool would work in Chrome. The most important buttons are accessible name and role. This tells the screen reader user that this is a button and what the label of the button is so they can interact with it. The deaf tools also shows you where they got the accessible name of the button from an in this example the text button shows the accessible name and the role is derived from the semantics element. It will not be exposed as a button anymore unless you add all the attributes to explicitly expose it.

 

 

---

If you expose it, you have to implement all the functionality using JavaScript, but why do you want to do that with the native button element provides that for free?

Using voice over Mac OS it would say "send message" button. 

Pretty straightforward.

---

What name the screenreader use for a button when there is no text? We need text to label the body any to add that, we can provide labels for screen readers only, there is more than one way to expose buttons to screen readers.

---

We can hide content in CSS: Using inset 100%, opacity to 0 , Visibility hidden, display none. 

These last two would make a completely inaccessible by hiding them from DOM and the accessibility tree. 

---

The first attribute is the heading attribute; it is the HTML equivalent of CSS's display none. It is hidden from assistive technology. 

(Speaker talking very fast, unable to capture all content.)

---

It is useful for hiding decorative or to picketed content for example decorative icons next to text.

Because they already have an accessible name for a button; of course that is assuming that the icon in the text label have the same meaning. 

---

 

So for example if you have a menu button that has a label and a menu icon you can hide the action by setting its value to "true." I am also using the focusable attribute and sending it to "false". 

---

(indiscernible)

---

So this can be used to hide content from screen readers while keeping it visually visible, why if you want to do the opposite?

---

Most of the times we need to provide text for screen readers only you want to hide the visually, for text the most common way to do so is to use Utility class. 

---

The visually hidden class sometimes called screen only class, it's raises the element into one pixel square, hides the overflow and positions the element to remove any trace of it from the normal document flow. We can hide element visually only, from screen readers only from both.

Let's see how we can create accessible icon buttons.

---

Keep in mind that we want to have the buttons have an accessible name, let's see how we can approach them. 

---

The first way we can create an accessible name for and I can button is by providing screenreader on text using the Sr-only text inside the button and the action becomes redundant so we hide it using (indiscernible). I have my button and my icon which is visible, my screenreader only text. Since the screenreader already has a label and already has the role implied from the button element, we hide it from screen readers.

We can use the text inside the button as an accessible name in the second approach is a very common and popular one. 

---

Once again we have a button that contains our SVG I can but here we are providing the button name using aria-lable. This is used to provide an accessible element with a string of text and the string of text will be used as a name for the button. 

---

  

  

A couple of things to note. He did not need to add the word button to the label because the screenreader will announce the role right after it's accessible name so this will be announced at the menu button. The content of the aria label will override the label of the content.

The contents inside the aria-label are not translatable. If a user uses a translation tool in order to translate the UI of your application there will not be able to translate the label of the button when it is provided inside the aria-label, something to keep in mind.

---

If you inspect this button in the deaf tools, you will see it is exposed again as a button with an accessible name derived from the aria-label. 

---

The third technique combines the first and second one. You have text that you can expose the screen readers inside here. But you expose it using another aria attribute, aria-label by -- it derived from the contents of the element it points to not return values so in other words aria-label by take the idea of another element in this case -- (indiscernible) in the text content will be used as an accessible ---

This is not go to technique for adding an accessible name for  adding names to icon buttons. (indiscernible)

The answer is simple even though it hides it from screen readers we can still expose them to the by referencing them inside the aria-labelby. 

---

  

  

If we inspect this button in the deaf tools, we can see that it is exposed to the button with the accessible name derived from the label that the aria-label is pointing to. 

They have their own rollbacks and compatibility issues but I have written an article in my blood in which I go over the details of these techniques that I highly recommend checking it out, so we covered the basics of hiding and exposing the content of screen readers that there are instances where these techniques fall short. 

Specific when you find the need to hide an element in an attempt to create custom alternative styles, checkboxes and radio buttons are a good example of that and in the section I want to talk about checkboxes and the principles are covered will apply to pre-much every other interactive element in order to create a custom style check box   we need to hide the needed check box and replace it with an image of the check box because we cannot stop the check accesses own but the image replacing the checkboxes at the end of the day are just an image,  visual replacement of the real checkboxes so the user still need to check box to interact with.

Screenreader recognizes an image as an image; therefore when we hide the check box we still need to make sure it is exposed to screen readers. Typically when we use an SVG imager visually replace the check box the code would look something like this, and this is what I recommend.

I would have the label wrapping everything, (indiscernible). 

---

Inside of my label I have my check box, I have my SVG that is going to replace it and the text label and at this point the check ox is still visible but before we hide it where going to apply some basic status of the SVG. Positioning and sizing into the text so that it scales with the text and then we style the background and checkmark and a default state and the check state; we also don't want to forget our focused also when the check box receives a focus we show an outline around the SVG check box and we use a sibling selector to apply focus styles to the SVG link.

---

Finally we need to hide the native checkmarks and this is the most important part. Which hiding technique would you choose for hiding the check box? Since we want to make sure that it remains accessible, we rule out all the rules to hide it from screen readers and is usually leaves us with the two most frequent answers. One, using the visually hidden utility class which sounds like the right solution because it hides the check box visually while still exposing it to screen readers. Two, move the check box off canvas and hide it using absolute positioning and this removes the check box in view not from the accessibility tree.

---

It is true that both of these techniques hide the check box visually and still would be accessible by the screenreader but neither are inclusive of users navigate by touch.

---

 

 

One of the ways is to explore by touch which means that a mobile screenreader can literally move their finger on the screen, on the page looking for interactive elements. The way you hide the check box determines whether touchscreen reader users will be able to find their not. As you can possibly imagine, hiding the check box off canvas will make it inaccessible to them they will be unable to find it is a drag your finger around. Similarly shrinking the check box will be difficult to find in touch, so while they can be good to hide static content it should not be used to hide interactive elements.

---

How do you hide interactive content? Hiding visually. Touch users can find it with haptics where they expect to find it; take the speaking this means remove the check box from the page level using position absolute so it does not take up any unwanted space visually and positioned it within the label making sure that it is position on top of the image that it visually is replacing. 

---

You can resize it optionally and then visually hide it by making it transparent with opacity zero. 

---

And finally since the native checkboxes still exposed to screen readers and I have a visible text label to go with it once again the SVG images redundant and relevant so finally we will hide it; and this is how you hide interactive elements accessibly. This applies to any item you need to hide in visually replace with something else.

For more detailed recap on this technique you can refer to the article I wrote about it on my blog.

---

There are many ways that people browse the web and too many to cover here in the short talk but there is one small tip I would like to cover, one small tip to optimize your experience for keyboard users so they too can navigate your content.

---

 

 

In addition to always ensuring that your interactive elements and components have proper styles you can use the tab index attribute in ARIA to create a more efficient experience for keyboard users. The faster the user can navigate the UI the better; the less tab steps, the faster they will get to where they need. Blogs and online magazines and other publications will normally display list of articles and post. A post entry has a typical anatomy normally consisting of a thumbnail, post title, author name, post tags, description and read more link. Typically the post tag and read more link to the same page which means the keyboard user tabbing will have to tab through three consecutive links to the same page. An example is the Forbes page, posts contain three links: thum nail, post -(indiscernible) -- so a user navigating using the keyboard practically needs to tab the same link three times in a row to continue navigating the next post and whatever content comes after. The more posts there are, the longer the tabbing  journey will be and similarly the New York Times has post links with two links. 

---

Medium is another example with five length for listing; if you use a keyboard a lot you are starting to note how redundant it is to tap for the simile multiple times in a row which a list of post is designed for such a structure, is usually optimized for sighted users or mouse users. 

---

  

  

When the keyboard user needs to tap through the same link two or three times in a row, they are slow down because her journey becomes literally 200-300% longer than it could or should be. We can do better. 

---

Depending on the post structure anatomy we could drastically reduce the experience. 

You prevent the link being tabbed by using tab index = -1, and hide settling from screen readers using aria-hidden. 

It looks like this: I have my article, the link, another link which is the title at another link which is read more link or read more icon.

I only want the heading or the title of the post to take me to the full article page so for the thumbnail and the read more links I add aria heading "true" and the tab to -1. 

---

In the examples we saw the Post excerpts are short and there are no links. When there are several things within the title and read more link, the read more link should not be skipped because it improves the user experience. For example I recorded the process of tabbing through the Lea Verou's website. 

---

Because there are quite a few links feelings after the post title each entry, the container reading link here is essential for the keyword experienced. The link is a shortcut in this case to the full article page and had not been there, or if it were skipped the user would have to go back to the full title to read it,  counterproductive and this is an example of what you do not want to use a tab index in aria because it would worsen the user experience.

---

Each design comes with its own usability considerations any to be taken into account; in order to improve your experience you need to test the design using your keyboard and with real users if possible. 

---

A good rule of thumb for similar cases is if you have multiple consecutive links to the same page there is a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops. There is no one rule fits all.

---

 

As with previous sections, there is a detailed writeup about this case study on my blog.

---

People come in different colors, ages, sizes, backgrounds, abilities and disabilities and context. This diversity is beautiful, motivating and inspiring. As web designers and developers we have a chance to include everyone and we have a response ability to produce a web that does not include anyone and throughout the stock as you saw it takes little effort to create more inclusive, accessible expenses and I hope this talk has inspired you to approach building interfaces the more observing eye, more positive attitude and my curiosity to learn about your users 

And inspiration to bill for the people of the World Wide Web. 

Thank you. 

>> RYAN BATEMAN:

Fantastic Sara, thank you for your time. 

I have a number of questions.

If you like I am going to start at the top. The most popular question is, 

what are some tools you would recommend to preview menus and landmarks on pages?

  

  >> SARA:

I don

t have a favorite one, I use one of the machine which is called a voiceover. 

Someone mentioned it also, only available for crown and as a Chrome extension. 

>> RYAN BATEMAN:

It's an Edge extension as well. 

>> SARA:

I personally prefer to use the screenreader and the rotoer. Just a couple of keystrokes. 

>> RYAN BATEMAN:

You covered a lot of amazing content specific examples.

Are there SEO implications for using visual headaches?

>> SARA:

I heard a tip from a friend that SEO takes care of itself if you're putting great content, so if you're putting a great content you won't have to do a lot of stuff for SEO. 

We are hiding them in a way that hides in visually but they are still there and still exposed to screen readers and Google search. 

>> RYAN BATEMAN:

Thank you. 

Myself working in marketing, if the screenreader can accurately crawl your site a Google bot probably also can. 

>> SARA:

That's a good way to put it. 

 

 

>> RYAN BATEMAN:

Next question I've got.

With the button labeled screenreader only text, is it better to append the screenreader text at the end or use ARIA to add more context from another element?

>> SARA:

With a button labeled screenreader only text?

I would talking about the label of the button?

It's better to append at the end?

It depends.

If you want the text to be part of the accessible name of the button, then you place it inside of a button, if you want it to be a description, I would probably not be using ARIA described by. An example is if you have an email address the label would be your email address and input. The screenreader will announce input, accessible name and after that a short pause followed by whatever you are referencing. ARIA described by ads and at a description that antitype of the element and the accessible name so you have a slightly larger description like what email should be.

With buttons you should not have long screens of text. 

If I understand the question correctly that would be inside of the button and if I can answer another related question at this point, someone asked if it is better to add text inside of the button and then hide that element or add the label inside the ARIA label attribute. I would say use the child span inside of the button because with ARIA label, there are issues with translation, if it contains text the necklace the user may want to translate it to Spanish but the text inside

Will not always be translated so better to use actual text inside the button rather than visually having. 

 

 

>> RYAN BATEMAN:

There are quite a few questions -- I'm not sure that you can answer these but we have specific questions about the difference in screenreader programs, one particular is asking what sort of experience do you have in working with others aside from voiceover on MAC like JAWS or NVDA? Can you help clarify maybe some of the differences when testing with them?

>> SARA:

I personally do not have any strange because I only have MAC machines, I do not have access to Windows machines. I rely on the expense of other people. My favorite reference is a friend called -- She does all the testing and shares incredible research. He works with real screenreader users and tests across myriads of screen readers and he shares his research and there are a lot of people working who are sharing their research, the results of their experiences and tests and me just like a lot of people, we rely on what those people share with us, at the not have experiences with other screen readers myself. 

>> RYAN BATEMAN:

Maybe we can fit in one more question here. 

What is the best way to describe clickable items for screen readers? Are there links? When using router buttons only for interactions?

>> SARA:

interactive items will either be a link or a button. The way to describe them is to first of all use the semantic elements so use button for buttons, links for links; if you absolutely have to deal with code that you did not write yourself, like a div that is behaving as a button then use ARIA attribute is to tell the screenreader that this is a button so would use role button, but when you do that you need to be aware that adding role button to a div does not add interactivity that the user expects on the button so you will need to use JavaScript to make sure that that div is clickable and the user can interact with it using the space and enter keys. 

>> RYAN BATEMAN:

Thank you so much for your time Sara. We appreciate the massive amount of value and information you were able to give us today, sincerely appreciat it. 

Thank you all for joining us. 

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

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

Type: Breakout

Track: Design

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

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

 

 

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

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

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

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

 

 

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> VINCENT ANIORT:  Yeah.  

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

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

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

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

>> NATHALIE PICAN:  On the summer.  

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

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

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

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

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

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

>> VINCENT ANIORT:  Yeah, it helps.  

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

>> VINCENT ANIORT:  Nathalie.  

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

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

>> MODERATOR: Thank you.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> MODERATOR: Good point.  

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

 

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

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

 

 

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

>> VINCENT ANIORT:  Yep.  

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

  

  

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

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

 

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

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

 

Agile Accessibility Requirements at Scale

 Agile Accessibility Requirements at Scale

Type: Breakout

Track: Development

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 So that is my first component done.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

  

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

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

Auditing Design Systems for Accessibility

Auditing Design Systems for Accessibility

• Type: Breakout
• Track: Design

 

Design systems are a crucial part of building accessible experiences. Each atom, molecule, and organism we create in our systems affects our ability to scale upwards and meet disabled people’s needs. In this session, learn how to audit components for accessibility issues from design to code using plugins, best practices, and testing tools. Walk away from this session empowered to make your design systems accessible sooner. 
Hello to folks who are just joining us. This is Laura Gosselin from Deque. We are going to get started in a few minutes so sit tight. Looks like we have got folks joining us from the Netherlands, Baltimore, hi to folks in the UK. Hello and welcome to everyone from around the world. We're super excited to have you with us. We'll get started in a few minutes.

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

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

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

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

Wait!

Hold up!

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

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

What should we be auditing design-wise?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>> Great!

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

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

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

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

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

Why are we using it?

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

Are we showing users they can use this  eventually?

Do they know how to use this eventually?

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

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

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

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

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

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

 

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

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

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

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

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

>> Thanks everyone.

 

Serving Everyone: Accessibility for Public Benefits

 Serving Everyone: Accessibility for Public Benefits

Type: Breakout

Track: Design

Public benefits programs like Medicaid and SNAP must serve everyone, but too often treat accessibility as a to-do list item rather than a core value of service delivery. How should we define access for our neighbors with low incomes who have been and remain systematically oppressed, whose only way of accessing the internet is through a smartphone on a limited data plan? Join Code for America staff as they discuss their work with various state governments to build a social safety net that is truly accessible to everyone.

 

Notes

-don't overwhelm people with questions
-keep language simple - 5th grade
-mobile first most low income people only have a mobile phone
-links should be specific about what is next (i.e. not more information but information about X)

Closed Captioning
 

CAPTIONING PROVIDED BY:

ALTERNATIVE COMMUNICATION SERVICES, LLC

www.CaptionFamily.com

* * * * *

This is being provided in a rough-draft format.

Communication Access Realtime Translation (CART) is

provided in order to facilitate communication

accessibility and may not be a totally verbatim record

of the proceedings

 * * * * *

(it seems to be missing the start)
 

>> And most of all, it guarantees that the needs of people are put first. So when delivered  effectively, a human centered safety net has potential to make a transformative positive impact on people's lives. So today we are going to use the social safety net as an example of government services because it's the one that Deirdre and I work most closely in but it does extend to other government services and agencies and types, like, for example, the criminal justice system. Some of the principles here around human centeredness are around first many welcoming doors, providing equitable and positive experiences in both online and offline worlds. Second principle, that the system is easy to understand, that people should be able to make it through the process with minimal support. The third principle is around informed decisions that people should clearly understand implications of all the actions they take throughout the process. The fourth principle is that it be responsive to changing needs, that the system itself change based on people's real needs as well as shifts in policy and budget and in the world at large.

And the last principle is around simple actions, that each stage in the enrollment and eligibility process should be completed in as few steps as possible. So unlike the private sector, government has to serve everyone. In the private sector in commercial products or services, they can usually choose their customers. They will target the market. But government doesn't get to make that choice. And for good reason. Government has to and absolutely should serve everybody. And that means that government products and digital products like the topic of Axe-Con, have to be accessible. So they have to follow the accessibility standards because there's a mandate for them. So that means something like the revised updated section 508, it means WCAG 2.1AA and this is honestly really great for us as accessibility advocates working in the government space, that there are clear mandates, that there are accessibility professionals embedded within government who make sure that any tools, any web  tools, any digital tools that are published by the government are accessible. This isn't usually the case in many industries. It is the case in the government public sector and it is great that it is the case. We fill at things like the VPATs, the voluntary product accessibility template. We use Axe core and Axe tools to automate accessibility testing. Code for America even has its own accessible design system called honey crisp and that gives us a great accessible starting point that features accessibility as well as being really user friendly as well as mobile friendly. Government digital products have to be accessible. That's sort of the necessary but not sufficient case. The reason we say that is because government services also have to be accessible. So what do we mean by services?

In most states, for example, people can apply for public benefits in multiple ways. This gets to the many welcoming doors principle that I outlined  earlier.

So they can apply maybe through an online application, and yes, it definitely should be web accessible, accessible for blind, low vision, Deaf users. But they can also apply maybe through paper and mail it in or fax it in. They can apply over the  phone, so they may be able to call a call center, call a hotline and apply that way. And before and hopefully after the pandemic, they could apply physically at a human services office.

So our work is much more than digital. The government services base is much more than the digital realm. Services take place at all these other places, right?

So accessibility has to also extend beyond digital to these other places and spaces. So what does accessibility mean for a holistic, complex government service?

I'll handoff to Deirdre to talk about that.

>> Thanks, Luigi. We know that there are services outside of the digital ones that government is responsible for. And like many things, services don't just appear. They're designed!

So we want to introduce an idea to you all and see how you take it, but thinking of the service design, the design of these services as a principle of accessibility. So what does that actually mean?

Let's talk about what service design is. On the next slide we have the definition here from a book called:  This is service design doing. The way they define service design is service design is design for experiences that happen over time and across different touch points.

So this is interesting for us because we think about digital accessibility as one aspect of that but in all of these examples that Luigi gave of different ways that folks can start the benefits application journey, they are not all digital. What happens when you're at a physical office space?

What are the expectations when you call up to apply?

What are the ways that the paperwork is designed in such a way that is accessible for people?

So we want to consider all of those. So we won't -- on our next slide we laid out flat. We believe that when a service is truly accessible, it is accessible at every point in the process. So that's in all of these different ways. We have three main strategies that we are going to introduce now to sort of explain how we think about making services accessible at every point in the process. So on the next slide we have our first strategy. Our first strategy is no wrong door. When a service is truly accessible, it's accessible in many ways. So no matter where someone starts, that place should be the right place. For public benefits applications, that could be over the phone, in person, on the digital platform like Luigi was explaining. And when they actually get to that place, wherever they start, which is the right place, they should be able to speak their language. So it should be available in many languages.

 

 For public benefits in many states, the human services department contracts a language line and they can conference call with an interpreter so that no matter what language someone comes in speaking, they can be helped by the human services representative that's there, that staff member, even with staffing limitations. That's one way that states make it so there's no wrong door. And websites should always be available. They shouldn't have business hours. And you might think I'm being dramatic. What website has downtime now?

But many states' services departments do have planned downtime. For instance, Georgia gateway, which is a website to apply for SNAP, Medicaid is actually closed for planned downtime many times a week. In one instance we saw it was actually down for 13 hours. If you wanted to apply on Sunday morning, you would have to wait until 10:00 a.m. to use that website. And it's really tough because we expect that people are not going to be in the office all the time, call center staff may not always be available, but websites should be that 24/7 access point. So not only do they have to adhere to WCAG standards; they should also be available all times of day. That's our first strategy that when a service is truly accessible, it's accessible in every way.

Our second strategy is mobile first. So when a service is truly accessible, it also has to be accessible on every device. In the social services realm we really think about this quite a lot because we know that especially people who have low incomes, rely on mobile devices as their primary means of accessing the internet. According to peer Research Center about a quarter of low income people in the U.S. use a smartphone only to access the internet. If you design a website only available on a desktop, it's not really going to serve a vast group of people. And it's particularly resonant with people of color. We see these same kind of trends among all income levels for people who are Hispanic and Black. So we're thinking about the actual device itself, right?

We're thinking about a mobile device or tablet, we're thinking about internet access, but also the form function itself of a mobile device can be incredibly important when thinking about social services. For instance, part of the application experience that Luigi will go into a little bit more in a minute is uploading documents. So people will have to prove that they're eligible for a given program by submitting their pay stubs, for instance, or submitting a copy of their rental agreement. This can be really challenging when you have to mail it in, when you have to use a fax machine, when you have to bring it into the office. But digital is actually a great way to submit documents and we think of a mobile device as an ideal form factor for submitting documents. You have the document in front of you, snap a picture on your smartphone and upload it. These are ways we're thinking about mobile first as a strategy not only in the digital accessibility but the other functionality that mobile devices can have. We're sort of extending our understanding of accessibility beyond digital accessibility, per se, to a service, the entire service.

And the last strategy that I want to introduce is plain language, which is very familiar to this audience, I think. When a service is truly accessible, it can also be understood by the largest group of people. Language comes in in a variety of ways into a process of signing up for benefits and maintaining public benefits. So not only is there that initial application, there's the stuff before and after it.

So how do people learn about their eligibility for a given program?

How do people know which programs actually fit their needs?

How do people know what documents they need to submit, what the next steps in the program are, how they can maintain their benefits?

Language content is pretty much 100% of most benefits programs. So it has a huge impact on the way that we can make our services accessible. And so for us, that means that we write at a fifth grade reading level in all the materials we produce in our partnerships with states. We also design applications in a way that require minimal cognitive load. So that means asking as few questions as possible. For us that usually means one question per page. Remind me to tell you about this in a little bit when we talk about Minnesota. Luigi and I are on a project where we're designing a new benefits application for the State of Minnesota. We'll talk a little bit more about how this comes into play there. And also these questions that we write for states like Minnesota, we try to create them in such a way that they don't require mental gymnastics to be able to answer. I'm sure you've filled out forms that have a negative question with negative statements. We try as much as possible to make the question clear, concise and very easy to answer because we know that cognitive load is an issue with accessibility. And the last part about plain language is clear actions. One way we think about this with form design is providing options for buttons that actually tell you what the next step will be. So instead of saying next, we say continue on to a very specific next step that it will be, which is a better way to let people know what the outcome of their choices will be. So we really want to make sure that we're pairing whatever it is that we provide as an option going forward with a very clear outcome. So they always know what the outcome is going to be. To summarize, these are three main strategies that we think about on the next slide. We think about no wrong door, mobile first, and plain language. And we believe that using these three strategies in combination will actually be the practical steps to make sure our thesis true, our thesis being when a service is truly accessible, it's accessible at every point in the process. I've seeded this a little bit. I'm going to tell you a little bit more about the specific steps of the application and enrollment process to show you how we apply these strategies very specifically in our work.

>> Luigi:  This next slide shows the benefits journey. This is a journey map that we created from years and years of research in the public benefits space. I'm going to go over all the steps of the public benefits journey. So first it is around discovering benefits. So you hear about the benefit maybe, or you Google it. How do folks actually discover the benefits?

The second step is applying. We've already touched on this a little bit. Do you apply digitally?

Do you apply on paper?

Do you have help applying?

The third step of the journey is determining eligibility. This is usually happening at the government side, whether it's a caseworker or someone like that, a worker at the government puts in all your data from your application and determines whether or not you are eligible for that benefits program.

The fourth step is the notification that you are or are not eligible for the program.

The fifth step in the journey is actually using the benefits. So if it is food assistance, like the  SNAP program, that might mean using the EBT card, the debit card, at a grocery store. If it is a public benefits program like Medicaid it might mean using it at the doctor's office. The last step is maintaining benefits over the long-term. Many of these programs have renewal processes. The renewal can be anywhere from every three months to every six months to every year. So it really varies depending on the program. And at all those points, it's really important that we recognize that people can drop off, right?

  

  

 

We know a lot of people will fall off somewhere along this journey and they will have a hard time getting back on the program, especially at this last maintaining benefits step when people go off and on benefits, even though they're still eligible. That's called churn. There is churn in the program because maybe there's paperwork that's been missed or maybe a letter was just not mailed to the right address and people try to use their food stamps EBT card at the grocery store or they try to use their Medicaid at the doctor's office and they're denied. And that is a really hard situation and it requires the person on the public benefits program to really scramble and think about how they are going to resolve that situation. Let's talk about some of these steps in depth with some of the strategies that Deirdre previously talked about. I'm going to go to the next slide and talk about how people find out about benefits.

I think we can think of the no wrong door strategy that Deirdre talked about earlier. So if you were to apply for unemployment insurance, and maybe some of you have had to do so in the past year or so, or if you're applying for food stamps or any of the public benefits programs, what would you do?

Maybe you would search on Google. So there's search engines. Maybe you would hear about it from word of mouth. So you would have friends or family who know where to go. If you're digitally able, you would go to a government website if you have digital literacy. So you would find yourself on a government website. Then maybe you would have to figure out how to get to the actual application. That might be a little bit tough. You might learn about programs on social media. So we worked on a fantastic program called pandemic EBT in the states of California and Minnesota. And pandemic EBT was a program meant to fill in the gaps for school children who were on free and reduced lunch programs at their schools and who were missing out on those meals during the pandemic because schools were physically closed.

So the pandemic EBT program provided EBT cards, which are like debit cards, to families of these kids who could then buy groceries with those cards. And it was a brand new program created literally in months. And the way the word got out of that primarily was through social media, through school districts on their Facebook pages, on their email list serves getting the word out to parents that this program was happening and these are the steps to take to claim the benefits, which really, really helped families in need last year. People also find out about benefits through community-based organizations like food banks. So usually if folks go to food banks to get a box of  food, the food bank will also offer to help them and that family apply for programs like SNAP, like food assistance. So people find out about benefits in all these ways and we have to think about how to make all those different ways accessible.

Another step in the journey is around getting help. So people need to get help along the way. So there are, for example, multiple ways to ask for help and maybe different people prefer different modes of communication. So someone more digitally inclined might choose chat or SMS or text messages or email. They might prefer to communicate that way. Someone else might prefer to communicate over the phone, might want to talk to someone in real life. Other folks might prefer to go in person to digital services offices and unfortunately that hasn't been possible but hopefully will be possible again soon.

These services are complex. Most people who apply will report that they feel like they need to be an expert to navigate these systems. So for example, in Minnesota, as Deirdre mentioned earlier, we're working on an application for folks to apply to several public benefits programs. When people are applying, even though we have taken all these principles and strategies to heart, even though the website is very accessible, they still need help along the process. So we have installed a service called Intercom which is a live chat widget that goes on to any website. What we found is really just being able to get in touch with a real live person really helps people navigate the process, feel more comfortable with their answers, feel more confident that they are correctly applying for the benefit. And it's great to have another person at the other end to ask questions and to get answers and usually that person is my colleague, Deirdre, who is usually at the other end of that chat window.

So one thing around here, around this concept, around getting help is maybe after this try and see how you would get help. Maybe call, look up your local human services agency and just ask how would I apply for food stamps. What is that experience like?

I think you'll learn a lot. Another point along the journey, a very specific point is how people learn about their case status. So once people submit their application to a program, their number one question and frankly their number one source of anxiety is around the status of their case. When will they hear back?

Do they need to do anything else?

Has their case been lost in the system?

Here it's essential to set expectations with clear plain language about next steps. When to expect to hear back, when to know that maybe, oh, you should maybe call in. A case status usually unfortunately is not possible to find out for oneself. Here, again, multiple modes of communication are important. That no wrong door strategy really is important. As one example, we worked in the state of Louisiana a few years ago and our researchers looked into how people do this. How do people learn about their case status?

Turned out it was pretty much a rude Goldberg system. There was a call center, a hotline. If they called that call center, they would not get a real person at the other end. They would get a phone tree. They navigate the phone tree, they press three and then five and then seven and then one for a few minutes, maybe five minutes, maybe 10 minutes. Eventually they get to the right place, hopefully, which is a voicemail. That was the thing, you leave a voicemail with your request. So you have to hope at that point that you leave the right information, that you leave your name, date of birth, maybe social security number, maybe case number if you know it. You have to hope that when a call center worker listens to your voicemail some hours later, that they hear you well and that they can have all the information they need. From there the case center worker -- excuse me, the call center worker would actually write an email to a caseworker. So the call center worker did not have access to cases. Only a caseworker did. So they would then need to send the email with all your details to the caseworker. And then you have to hope that the caseworker can find your case and then call you back. If that was confusing, it's because it's a confusing process. And all of this was just a very complex system just to learn what's your case status. On the next slide we are going to start going through some case studies. So we are going to start on the next slide with Alaska. So we worked in Alaska a few years ago on a few pilots. In Alaska it's a very remote population, as you can imagine. Towns are  small. They're very rural. They're very far flung. There is low internet connectivity. So working with all these challenges around access, what did we do?

So we worked on the beginning of the benefits journey in Alaska. So here is another map. On this next slide there's another journey map and we're highlighting the first two steps of it where people can discover benefits and then they can apply for benefits.

So on the next slide for Alaska, we are going to talk about the Alaska fee agents system. So fee agents are Alaskans who help their rural neighbors apply for benefits. And on this slide there's a picture of a fee agent, so we went to Alaska and talked to several fee agents and here's one of them. She's showing us a paper application of the interview that she gives to folks, her neighbors really, who are applying for public benefits.

So this pilot was us essentially creating a prototype where we were converting this paper-only system where Alaskans could help their neighbors  apply. And the reason why this system exists, I should say, is because Alaska is so remote that there aren't human services offices in all these small towns. The government can't do that. So there are these local neighbors who act as fee agents who help out.

And the system was paper only. It was an interview process. The fee agent would usually sit down in the home of the person applying and talk to them and have a conversation about their situation and fill out this paper application with them.

So this was a guided application process. So I think that's really great. It's really great to have help when you're applying for public benefits. And it can be completed in concert with the applicants and the fee agent. And so we set out to make a prototype to digitize this process. So we were thinking about our strategies of no wrong doors, of mobile first. Well, in Alaska, there's low connectivity, right?

So especially in rural parts there's very low cell phone coverage specifically. With that, we designed our prototype to be offline available. So it was a mobile application. Could be run maybe on a tablet like an iPad, but it also had an offline mode so that data could be taken in and synced when there was connectivity again, maybe when the fee agent got back to WiFi or back to a less rural part that did have internet access.

So that was, again, thinking about how people are using the services and thinking about how we can build mobile first technologies that really don't have any wrong doors. Another prototype we did was around the case status problem I talked about earlier. This next slide has a picture of an Alaska woman holding up a paper prototype. This paper prototype looks like a web app, which talks about a tool called my Alaska and it is a log-in screen, but the only boxes on this log-in screen or this paper prototype are your name, the name on your case and your social security number and that's it. This is something that we'll talk about in a minute. It's a big issue around user accounts. And user accounts are really inaccessible. Instead, in this prototype we are talking about how can we identify someone using information they already know, their name, social security number, maybe date of birth. Making this log-in process easier and reducing burden on the end user. With that, I'm going to kick it off to Deirdre to talk about more case studies.

>> Cool. So I was telling you a little bit about Minnesota earlier. It's top of brain for Luigi and me because we have been working on this project for more than a year now actually with the State of Minnesota. And this project is an effort to build a new human centered, mobile first plain language application for folks in Minnesota to apply for SNAP, which are food stamps, and cash assistance programs and hopefully -- if you would like to click around yourself, you're welcome to. It's demo.benefits.org. And because it's a demo site you can click around without submitting any real information. Why did we do this in Minnesota?

Because Minnesota has one of the longest application times, sort of originated in a product that we did at code for America where we went to all 50 states and tried to apply for SNAP, cash programs and Medicaid. And if there was a digital option available, we tried to go through that entire application ourselves. And what we found is that the state of Minnesota, if you would like to apply for both SNAP and Medicaid in Medicaid, it will take the better part of two hours to do so, one of the longest in the country. The staff agreed that's not okay so we started a partnership to improve it. It's also really hard to find the applications. You might think, well, I'm experiencing some hardship, I need help paying for food and medical bills, why don't I just go online. There's this one department. There will be one application, right?

But not so!

There are two. And finding them is pretty challenging. So I'll echo Luigi's suggestion from earlier that you go for your state or the state of Minnesota and try to find the applications for these programs and it's no easy feat, I'll just give you a forewarning.

Let's talk about where we are in this process. In the next slide we're bringing up the same journey map that Luigi was showing you earlier with the next steps for applying and maintaining benefits. For the project in Minnesota we're focusing on the applying for benefits. Once you find the application, it doesn't get much clearer. On the next slide we'll talk you through the real problem that we see that actually stops people from beginning the application. And that was user accounts. Like I said, there are two different applications, one for Medicaid and one for SNAP and cash programs. On the right side of the screen we have a screenshot of the user account creation profile for apply MN, which is the SNAP and cash application for the state right now. People can't get through it. And this is an accessibility issue. You can make an application that's all to the top standards of digital accessibility, but if folks can't even start the application, it's a moot point. So this further reinforces our point that accessibility has to take place at every single step in the process. Our project right now doesn't require a user account to start. I want to just give you an example here of how this comes into play. On the next slide you'll see a screenshot. This is a picture of a client holding her cell phone. You can see the same website, Apply MN, on her phone. The type is incredibly small because it's not mobile first. It was designed to be used on a laptop or desktop computer. What this means is especially for clients relying on their cell phones to access the internet, this becomes a herculean task to try to actually start the application to find out where to begin. Looking at this screen, you see a big block of text in the middle. You think there might be some menus on the side, but there's no big digitally accessible button, no big tappable area that says start or apply. So it requires a lot of hunting and pecking to figure out where to even start.

It's a real problem. On the next slide you'll see the client was trying to do some problem solving here. Now she's turned the phone sideways. She has it in landscape mode and you'll see a big red bar. The beginning of the bar says the password entered is invalid. It goes on to explain all the password criteria. These are the characters you can use and these are the characters you can't. And none of this was provided as guidance in password creation on the previous screen where the client tried to actually create the password in the first place. Needless to say, this is really impossible. This client happened to have access to a desktop computer and she went on to that computer, went through the whole process and actually she got stuck inevitably again because her cookies were filling in a user account and password for an old application with the same Department of  Human services for a different program. So savvy person that she was, she went to her cookies and cleared them, something I wouldn't have even thought of, and was able to create a password and begin. This was the better part of 20 minutes where she was trying to start the application. And it doesn't take a great leap of imagination to understand why this is inaccessible. We know that we're seeing a couple of the strategies we talked about earlier. We're seeing mobile first come into play, we're seeing plain language, and these things have a huge impact on people's ability to get the help they need and deserve and pay for with their taxes. Last case study, we're nearing our end, we want to start with the work with Louisiana. In Alaska we have neighbors helping neighbors start the application process. Minnesota we see how just getting rid of username and password requirements lets people start the process. In Louisiana we were trying to tackle a different part of the benefits life cycle. On the next slide you'll see that same benefits journey and we are going to focus on two parts here. We're going back to part two, applying for benefits, and the last step in the process, part six, maintaining benefits. What do we mean when we say maintaining benefits?

All of these programs, in Medicaid, SNAP, cash assistance, clients not only need to apply to get  help, they need to fill out additional paperwork, maybe talk to a caseworker, maybe submit additional documentation at various touch points along the life cycle in order to maintain those benefits. So that could be for a SNAP client at six months they need to fill out a simplified report, pretty short, basically saying I'm in the same situation that I was six months ago when I initially applied; nothing's changed, I'm living where I'm living and earning what I'm earning. Or it might be at 12 months. We developed this idea of churn earlier. If you miss one of those things, you'll lose access to your benefits entirely and have to start from square one from the very beginning of the application process which is really onerous. In about 2018 and 19 we at code for America partnered with the state of Louisiana to try to intervene in some way to help people stay on benefits so they didn't have to reapply. So on the next slide you'll see a summary of that project. It was multi-program. So all the programs I was talking about, a one-way text messaging service where we broadcast reminders and guidance to clients at these key enrollment periods, these key points. On the right you'll see a picture here of two women and one of their very small babies who we were interviewing at a WIC clinic, women, infant and children, a program for women and children up to the age of five. We asked participants to explain what was going on with WIC in particular. Many of these clients were co-enrolled in other programs like Medicaid and SNAP as well so they had invaluable insights to share on what could help them stay on the benefits and make that life cycle of benefits be easier. What they said was every three months, at this time in Louisiana there were paper vouchers. So if you were participating in WIC in the women, infant children program, every three months you would come into the office and say yes, I'm still eligible for this program, here's my proof and you would get a piece of paper with your vouchers. As of 2019 all 50 states have EBT cards which is a huge difference. Needless to say, if you don't show up for those three-month appointments, you don't get the benefits. So showing up is really important. Up until our intervention, the only way that mothers, usually mothers, would know that they were due for an appointment is they would get a blue booklet at the end of their appointment. It would have a sticker on the back that says your next appointment is at this date and time. Now, imagine, you have this piece of paper, this folder. How many times have you lost a folder?

For me, many times. For many people, they didn't want to lose their folder so they put it in their purse that they carried around all the time, but the sticker was not the highest quality sticker and the date and time would rub off. It's really hard to remember when to come back. On the next slide, I want to show you what we ended up sending. We worked with the participants in this program and piloted a lot of these kinds of messages and got feedback, they told us change this word, change that, this is what would  help. I just want to read the two text messages on the slide. Three days before the appointment, we would send one reminder that said your WIC appointment is at 1/21 at 9:30 A&M at the office located at this  address. This appointment is to pick up your vouchers and will take about 30 minutes. You don't need to bring your child. Remember to complete your online nutrition class -- this was all this language that participants told us that would help, basically. When is where the appointment is taking place, what it's for, what they have to bring, and the consequence of not going to this nutrition class, so sort of incentivizing. The day before the appointment we sent a second reminder that's a truncated version saying this is a reminder that your WIC appointment is tomorrow at 9:30 a.m. again, it's when, where, why, what we need to bring and how to sort of problem solve if that wasn't going to work for folks. This was sent via text message. This is not a website, not an app. We weren't thinking about WCAG. What we were thinking about is the form itself. We're sending people messages where they are going to get them. How many people have their cell phones on them all the time?

Most. Most people have their cell phones on them a lot. And especially for programs like WIC, when thinking about pregnant women and young children, they tend to be younger than most of the population, cell phones are sort of ubiquitous. We're trying to not only think of accessibility in terms of the digital form but also thinking of it in terms of the mode.

So by now I hope we've proven our thesis, that when a service is truly accessible it's accessible at every point in the process. And that means getting into the product, navigating the product, all the stuff that takes place around it, people, places, and hopefully you'll think about this too when thinking about a definition of accessibility.

That's all we have got. I think we went a little bit over but hopefully we still have some time for  Q&A. All right. Great work, Luigi and Deirdre. Thank you so much for your presentation. I think we can sneak in one question before we have to wrap. So here's a question from Jessica. She asks when it comes to getting help with accessing public benefits, what are your thoughts on chatbots as opposed to real live chat agents?

Are there some areas where chatbots do a good job and do you have any advice for designing them with accessibility in mind?

>> Deirdre?

Would you like to take that?

>> Oh, would I?

  

  

I thought you might. That's interesting. Chatbots are a tricky one. I think we use some triaging. On our other product that we have at code for America, get cal fresh, we have zam also set up, this chat service. And we have a little bit of triaging at the beginning to help people get started with the conversation with a real human. What I find really challenging with chatbots specifically in the case of government services is it's so hard to get in touch with a real human and if we can provide a way for someone to find even me who doesn't work at the county but knows enough about where to send people, it's going to be a lot more human and a lot more comforting than a chatbot. So wherever we can intervene and create a human interaction where previously there was one that was more mechanical, I think the better. Particularly in the system when it's so hard to get in touch with someone and that's the only way to get answers. That said, if there's simple triaging, we want machines to be used for the things that machines are good at and humans to be used for the things that humans are good at. It's a balance to strike for sure.

>> Well said.

>> That's a great point. All right. Well, we are at our time now. Thank you everybody who submitted a question. Sorry we didn't get to them, but we want to thank Luigi and Deirdre again for an awesome presentation with tons of real world examples of what they're doing and how accessibility impacts it. So thank you so much to our presenters and to our guests, I hope everybody enjoys the rest of Axe-Con.

 

How Designers Forget to Consider Accessibility

 How Designers Forget to Consider Accessibility

Type: Breakout

Track: Design

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

 

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

 

 

 

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

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

>> Thanks!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What considerations can you include in your test?

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

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

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

Who would not be able to use this?

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

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

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

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

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

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

>> Great!

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

>> Do I stop sharing or no?

>> You can keep the slides up.

>> Okay.

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

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

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

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

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

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

>> Thanks.