Main room transcripts
Transcripts courtesy of White Coat Captioning capture what we discussed in the main room at Accessibility Camp Seattle 2019.
- Conference schedule planning
- Conference Schedule Voting Instructions
- Hearts and Minds and Launch-Blocking Tests - Jesse Beach
- Afternoon Schedule Announcements
- Partnership Between Developers and Designers for Accessibility - Jessica and Casey
- Popular UX/UI Patterns and Accessibility - Matsuko
- 5 Rookie Accessibility Engineering Mistakes - Sophia Allen
- End of the Day Recap
Note: a caret > in the text denotes a change in who is speaking.
Conference schedule planning
MARCY SUTTON: Hello! Welcome! So excited to have all of you here for Accessibility Camp Seattle. I’m Marcy Sutton.
DEVON: I’m Devon Persing.
MARCY SUTTON: And we’re here for a day of accessibility. A day we get to shape together, so it’s going to be exciting for the next little bit, as we figure out our schedule for the day. So, housekeeping notes and tips for the day. We have live captioning, that is up here, on the screen. It might be hard to see, so we have a separate link that is bit.ly/a11ycampseattle. You can follow along in case the screen is hard to see.
So, here’s our schedule. We have now checked in and had breakfast, hopefully, get some coffee and tea. We’re going to kickoff today by deciding what our schedule will be like today. I’ll hand that off to Devon in a moment. We’ll have a lunch in here from Homegrown. You’re free to go out for lunch, if you want. I picked 1:00 p.m., does that sound good? We’ll plan to come back at 1:00 p.m. and we’ll wrapup, in this room, at 4:30. We have prizes. There is also swag at the back table, including notebooks and pens and stickers. I went here in high school, for running start, so, really going all the way back.
So, some social media, if you’re on Twitter or Instagram, we would love for you to use #A11ycampSeattle. That is the hashtag for the day.
This wouldn’t be possible without our sponsors. So, thank you to Shopify and Starbucks for the breakfast.
Our captioning is thanks to Deque Systems. Foundry Interactive helps us out and Sarah from Microsoft.
Let’s give a round of applause.
So, real quick shoutout, because we are all here together, if anyone’s looking for a job. let’s doing hiring, first. Who’s hiring for jobs? What companies are you with? I see Amazon, REI.
MARCY SUTTON: Who’s looking for a job? Okay. So, kind of† you know, if you can take note of† yeah. So, try to connect with each other, because there’s so much, like, wealth of knowledge in this room and this is what’s great about coming together in physical spaces. So, let’s use the day, shamelessly.
Get the most out of it.
Okay. So, now what we’re all here for is the unconference and I’m going to hand it off to Devon for the logistics of how this will work.
DEVON PERSING: One person can take this one. Okay. Who’s been to an unconference before? Okay. So, you were less freaked out than everyone else about the complete lack of a schedule for this week.
So, what we’re going to do, there’s nothing at this URL yet, there’s filler sessions. People that are interested in talking about something or demoing something are going to come up and use the microphone. We’re going to have someone basically pitch your idea, the thing you want to talk about and then we’ll make note of all those things and then, as a group, we’ll go to that URL and everyone gets to vote on what sessions that want to see and then we’ll use those votes to actually build out the schedule for today and create, you know, our calendar, basically.
So, we can just get started with that. I’m going to grab my laptop and we’ll get started.
Beth will be the microphone lady.
Okay. So, if you have a pitch, raise your hand or wave. Wave at Beth and tell us your name and also, tell us what your idea is.
I’m Sofia, I’m with Starbucks, I would like to talk about how to get big companies to take accessibility seriously.
Hey, everybody, Jesse from Facebook. I had a talk I give at a11y Toronto. The title for this particular instance, hearts and minds. So, I’ll talk about how we’re using launchblocking tests to keep errors from getting into the codebase of Facebook. Hearts and minds and launchblocking tests.
Hi, everyone, I’m Katrina. So, I’d like to learn more about how to approach interviewing and looking for the right people to interview in terms of disability. It’s like looking for the caregiver and also looking for people who have accessible issues to interview.
Hi, I’m Jessica and here with my friend, Casey. We’d like to talk about the partnership between developers and designers and remediation versus building it correctly the first time.
DEVON PERSING: I see lots of people nodding at that.
I’m Kristen and I’m interested in website accessibility and have slides from talks about web accessibility. My focus is on content, but I’d be interested to have a part to talk about code with context and content in code, from a user, design usability perspective, what makes a website accessible. What are some of the common mistakes and kind of could be one-on-one or could get more advanced. Whatever.
Chris, I’d like to talk about more inclusive web accessibility.
I’m Sharon and we would love to talk about how we make a convention for 11,000 accessible.
I’m Mark from Starbucks and my idea is to group together to talk about how to make a super simple, fabulous event registration page.
We should talk.
DEVON PERSING: So, the registration page. We provide some feedback to them.
MARCY SUTTON: So, just to add real quickly, on that note, it is kind of a pain. The way I’m trying to think of it is we’re making the world better. We may have felt some pain, but the impact will hopefully by hundreds or thousands of events that will have better accessibility.
I’m Kate. I would like to have a discussion about accessible maps.
DEVON PERSING: That one might be happening here.
I’m from Amazon, I have two talks I could give. Both related to the non-tech side of the house. How to design for the extremes in your population and why that matters more than designing for the averages and building a business case for accessibility.
I’m Jim, I’m in from Portland. I would like to talk about more inclusive accessibility.
It’s going to be in this room, too.
Hi. I want to talk about looking at popular UX/UI patterns and how accessible they really are.
DEVON PERSING: Anybody else?
An idea that I also got from an attendee, over email, if anybody’s working on something and they want help with that, we have space probably to do that in one of the rooms for a few hours. If that’s something people are interested in, we could add that to the list.
Did you say there’s someone from Microsoft here?
DEVON PERSING: I think there’s some Microsoft folk here.
It would be lovely to have a demo of the Microsoft Insights Tool.
Yeah. I have it installed on Chrome.
DEVON PERSING: Excellent. Yeah, that would be great. Good idea. One of the things that came out of the last time we did, a couple years ago, was a big Google Doc with a ton of links. We’ll share that. Feel free to add to that. We won’t have a session where people add to it specifically, but we’ll make sure people have access to it throughout the day. We’ll post a link to that on the website, as well.
Did you want to add something about the meetup?
MARCY SUTTON: Yeah, I was going to pitch one. So, this group is affiliated with the Seattle meetup so I wanted to talk about recruiting some of you so we can keep our community growing. So, that would be my proposed session.
DEVON PERSING: Anybody else? Anything that† sometimes someone maybe doesn’t want to lead a session, but wants to learn more about something. If there hasn’t been a thing that has been mentioned, that you want to learn more about, even if you’re not comfortable leading it, someone else might be. So, feel free to pitch those ideas, as well.
So, I would like to know more†
So, I would like to know a little bit more about tools for analyzing accessibility on the web. So, plugins or something.
DEVON PERSING: Would anyone be interested in running a session about testing tools?
I’d be interested in that. And, further, I’d like to learn more about the limits of accessibility and scanners and tools. I know† I work with some, but emulations only at best.
I’ll put in a plug for the topic I suggested, learning about Insight Testing Tools.
Hi, everybody, I’m Lane. User experience designer at Rei. Is anyone doing qualitative testing? Love to connect and kind of understand, like, tips on recruiting, best practices, kind of all of the above. I’d be happy to either lead that session or conversation or have someone with some more expertise do it, as well.
I would be kind of interested in case studies. Tricky situations folks have run into and what they did to solve that.
Switching to decaf.
Hello. I’ll Al and every time I lead a session, one session during the day that I absolutely want to go to is scheduled at the same time. And I wind up hoping that my pitch was so boring that nobody comes. So, this time, I’m not so much making a pitch for a session because I’m really selfish and don’t want to miss out on anything. But, I am trying to set up an advisory group of people from the community, who either† who are in this room. Because what we have, at my job, is we have a lot of people who want to make things work for our disabled users on the web, but we don’t have any actual users of the tools for technology. We can read so much from books. We can use emulators, we just aren’t the target audience and we need some guidance from people who actually are, to tell us, to ground us and say we’re in the right place. It wouldn’t be a huge commitment. Anybody’s got an organization like that, that you want to tell me about, or if you want to talk about it, grab me here. Don’t keep me out of the session.
Thank you, all.
Hi, there. I’m Andrew. Heard a couple people talking about the need for accessibility testing. So, I don’t think it’s a full session, but I’d love to talk about Fable Tech Labs who does this kind of testing. Maybe less than a year old, as a company, but had a really good experience with them. We can get together or anybody else who’s interested.
DEVON PERSING: Maybe some overlap with the usability session, in general. Maybe that’s a longer session. It sounds like there’s going to be a few topics. It sounds like there’s going to be a lot of overlap there, too.
Cool. Anyone else? Going once? Going twice? Okay.
So, we’re going to take all those. We might followup with people and say, did we write this don’t correctly. We’re going to put this all on this form. It’s going to be a bunch of checkboxes. Check the thing you want to go to. It’ll take us a few minutes and then we will have an actual schedule for you, from here.
Hold tight and we’ll be back in a few minutes.
Conference Schedule Voting Instructions
DEVON PERSING: Okay. Can we get everyone’s attention? So, we have updated the website with a link to the voting form, so if you go to accessibilitycampseattle.org, you can access it there. Go there. If you have any trouble with the form, wave your arm around.
Maybe pick the top four things you want. If everyone votes for everything, that makes scheduling hard. So, please pick the things you think you’ll really, really go to.
Also, feel free to talk to your neighbor about it. This isn’t, like, a secret vote.
It got very quiet all of a sudden.
There’s a short URL on the screen, as well. Marcy’s playing music.
DEVON PERSING: We’re all most ready to release the schedule. I also had a question for† if any volunteers, if I told you, you were going to be a room monitor and I haven’t given you a key card yet, wave your hands. The people in the back. Okay. Great.
MARCY SUTTON: Okay. So, all right. We’re ready to progress the day. I think it’s on.
All right. So, we have added a schedule to the website, accessibilitycampseattle.org. We have one session for lunch and five rooms, so you can pick which space and topic you’d like to hear about.
Here at Base Camp, we’ll have Hearts and Minds and launchblocking tests.
Room 3189, floor 3 will be Getting people at big companies to care about accessibility.
Room 3201, floor 3, we’ll have qualitative accessibility testing.
And room 3202, floor 3 will be making a convention.
In the afternoon, we have five rooms, again, and so, maybe we can talk more about those when we come back from lunch and you can get your game plan.
I have one more thing I want to tell you about. That I forgot to say earlier. We have a link to the resources doc and add your favorite resources for design or policy or getting accessibility moving at your company or development tools. That’s also linked from the home page.
We have a special link from Deque, they’re sponsoring this event. Axe, the browser extension, they’re doing Axe Pro version and looking for participants and the URL is http://deque.com/axe-pro-seattle.
With that, let’s put the schedule back up and then we can get this thing going.
Hearts and Minds and Launch-Blocking Tests
So, while we’re getting the AV Set up, how many developers do we have? Awesome. So, there’s going to be some code in this example† or, in this talk. We’re going to start out talking about linting and how that works.
So, yeah, plugin, started working on this, I think, back in 2017 with some folks, Evan† over at Twitter. And then, I want to talk about some of the more recent work we’ve done. There was one slide about it and I got examples from our code review tool because we’re just getting the initial data in about how we’re affecting user behavior and it’s amazing.
So, I’m super excited about it.
People had CI systems running. Does it stop you from going out? For accessibility issues?
Stop the code for coming out. Tell me more about that. For, like, Axe CI, you get a lot of failures. So we start with the threshold that you can’t go below. That’s just a percentage.
For something like Axe, I agree, you’re working with a site that has been up and running for years and years. You’re going to get such a flood of issues and the other issue† I don’t know if you’ve run into this, it’s difficult to route the issues. We have two moments in time, prelaunch and postlaunch, when we can intervene and the postlaunch intervention, at least I found, is impossible to do [Inaudible] you don’t have a way of finding the issue and routing it to the right team. So we have given up on that† I’m doing that sort of testing. But the problem is, that’s what a tool like Axe is really good for, for running over a page and finding a bunch of issues.
So, we’ve been looking for ways of intervening at the moment when they are going to get creative and preventing it from going into the code.
We also have the dimension of component versus custom code. So, Facebook, we probably have 20%, 30% of our applications being written in components that we’ve embedded and fixed. But the vast majority of the code’s going out on every platform, iOS and custom code. It isn’t like 100% of the app is going to be componentized.
Having, like, a formalized, known set of solutions. So, we can’t create new products if we only work from our component base. But if we’re not working from our component base, we have no signal.
Who’s worked with abstract syntax trees before?
It’s very hard to run over a file and look for the five function calls to create an HTML element and interpret that where we can look at something that looks like XML and understand.
So, let’s run through what linting and ESLint is doing. If we were to take that† that structure, which is less than div, with the attribute role, close element. If we turn that into an abstract syntax tree, we are going to represent them in structures. Think about this in terms of grammar, nouns, verbs, adjectives. Whether you’re talking in Spanish or [Indiscernible], any other language around the world, we can talk about that language in terms of its language.
So, let’s run through what the pieces of the tree are and let’s run through what a linting role is looking for, to determine if a role is valid or invalid.
So, our function gets passed that node from the abstract syntax tree and now we can inspect it.
We’ll do cleaning and pull out the property name from the object, so the property name is going to be role, cast it† yeah, it’s going to be role and if it doesn’t equal role, because we’re getting every attribute in the JSX node, we’re going to bail. If it is role, let’s do some checks. Let’s see if the value exists in known valid values for the node. We get the literal value from that property.
And then, this is just doing a filter check through all the node roles and if it does exist, then we just bail out of our function. If it doesn’t exist, we create a side effect where we tell the reporter that we’ve got a violation and we give it the node and our violation text so a human can understand what happened.
And this is the basics of any role. We’re getting nodes from the abstract syntax tree, doing some works and creating side effects.
All right. So, linting is one of these faculties that can answer some questions for it. It can answer pretty interesting ones like, “does an interactive element has a role? Does it have a label? Is it being using correctly. Our developers mangling it? Something I see a lot of, someone taking, let’s say a button and making it a list item or vice versa, learning. Chrome will let you do it, but it’s not great.
Are they casting elements to interactive elements?
So, this is the link to the plugin, it is ESLint plugins.
The tooling, a warning doesn’t prevent you from moving forward, but an error does. When we make something an error, we create a high degree of friction and one of the issues with linting is that it is in discriminate. All of the roles that are violating are going to be present. We’re not concerned with the code that’s violating. So, we’ve had a lot of trouble keeping these rules turned on as errors because if there’s any instance in codebase, we can’t expect a developers to fix it.
So for the most part, on our old site, we have most of these rules as warnings. We can never get new instances of that error going forward.
But, we announced, a month ago, that we have a new version of Facebook coming out. Our next iteration of the website. Going forward, all of these things are going to be. We had that moment in time and we had to seize it. If we waited half a year to do that, it probably would have been impossible.
So, takeaway, if you ever get the chance to greenfield a project, dial up the friction as soon as possible.
All right. So, looking at violations of these various rules, over time, this is from the beginning of 2016 to the† what was it? Sort of the end of October 2016. This was the initial run of the plugin that I checked. There were 80, 000 modules or files in our codebase. We see that unclick has role and focus, meaning we’re asserting that is true in the rule for the highestfiling names across 75,000 files.
All right. So, let’s look at what a developer might experience running through some of these rules. This is a pretty common pattern. I mentioned this one before. We have a list, UL LI. They have turned it into a button, which doesn’t feel great. Should we enumerate it? We’ve mangled the semantics. We told the developer, you’ve turn it into a noninteractive thing.
We can enumerate the number of things and express it.
But our developer, being clever, goes ahead and flips it and says, what if I use a button and turn it into an item? So, we’ve got a rule for this. Don’t turn interactive things into noninteractive things. There’s so much misinformation about semantic HTML so we decided, why don’t we make a list of rules that provide guidance?
We’ve got a rule that checks for tab index numbers, to prevent indexes, values that aren’t negative 1 or zero. And, we’ve got a rule that tells you when you’re missing required ARIA attributes. If you’re trying to create a slider and you have value max, value min, you do ARIA missing now is the one we’re missing here. And I’ll tell you about that, too.
We had to understand the intersection of ARIA and what the browsers do to represent these semantic structures, the accessibility tree. So, this is the tree that gets created from an HTML document and then gets expressed to an assistive technology and that tree has its own representation of your document, with objects like AX button, AX grid, and its own set of attributes. So, we represent that in a node module and make it queryable so we can ask, what are these HTML elements and if I’m looking at an A tag that doesn’t have an href, it’ll, say, no, that’s nothing.
Doing this work, I found out our notion of HTML, semantic HTML, is really offbase. There are a ton of elements that seem semantic like, all the keyboard stuff, KBD. A bunch of stuff around† what is it? Yeah. Not coming to mind at the moment. But what ends up happening, they don’t have equivalence, which means they don’t get represented to the accessibility tree. So, whenever you see someone talking about semantic HTML, forever, from this point onward, understand that there are a ton of HTML elements that don’t have, like, an expression in an AT as being semantic.
All right. So, on this screen, there’s a div element that has 0 and a onkeydown event and it calling click on the element and an onclick for saving. With all of these lint rules, developers were doing the work to add a role and tab index and then at the end of it, we had just a ton of extra stuff in our JSX files so we created a role that says, if you’ve done all of this, just use a button.
You’ve gone through all the work, reduce it down to a button and you’re going to get there.
Which people don’t do, so we have† in that recommendation, a second recommendation, we have a clear button, no styling. If you don’t want the button styling, use this other component. And we’ve found that folks do this and you would think frontend developers would know this, but no.
All right. So, anyway, we put a ton of work in, in 2017, to refactor this plugins rule. They were firing too much, they weren’t great, they weren’t understanding the semantics. The list of 12 things on the screen is the list of updated rules. We battletested these and had a view adverse side effects, but not a ton.
Let’s look at what we’ve achieved here, a screenshot of someone adding an onclick event to a div, which has a class button, but that doesn’t represent itself as a button. This is our internal editor, at the time they’re writing code, they see this warning that says, “visible noninteractive”. And then, we already talked about this. This is a representation of the experience of a developer walking through the lint or telling them they’re doing stuff wrong. So, they added an onput to an LI, a warning, noninteractive roles. It doesn’t have a tab index, so they get a tab index warning and then in the end, use a button.
So, what does the codebase look like after we set these rules and set them to warnings and fixed thousands of them† which I’ll talk about more. We saw a dramatic reduction in nonsemantic HTML in our React codebase, many thousands of violations down to many hundreds and we’ve seen these maintained. Developers will get around everything you do, so we have bots we run that look at change requests and look for the ESLint and we ping them on messenger and say, hey, why are you suppressing this?
I love developers because they will find the path of least resistance every time.
Okay. A few insights about this, developers create a lot of buttons, hundreds of buttons, the curve for elements in your codebase. Buttons are number one, by a factor of two. Developers catch clicks a ton. They put click catchers, like, wrappers in their code. And because of that, it’s ambiguous what the role should be, should it be a button or should it be some other role? We recommend presentation because it’s not something a user perceives, but that produces a lot of confusion with developers.
They turn off rules that annoy them so we created components that help them make it easy, like a higher element for React. It sets an onkeycalldown. Developers dislike warnings.
Some of the unintended consequences of this work, everything’s a button. I got a warning, make it a button. Go, go, go. We’ve seen buttons and buttons, which is terrible because a button inside a button doesn’t work. We see incomplete semantics. People adding a menu interval to a menu, but they don’t add the menu to the container components so we have these orphaned list items, menu items, grid cells that aren’t in grids.
When you think about where to spend your time fixing your interface, focus on buttons. You will get 80% of your code fixed if you fix your buttons. Labels, make them actionable and you’re practically done.
All right. Just some examples of bad things.
Next steps, so, this is the next step we were thinking. The problems that we’re seeing are not problems of instance or problems of combination because we have developers that are making perhaps the correct decision in that instance in their file, but they’re not making the correct decision when that component gets combined and there are two ways to know if it doesn’t seem correct. When half of the code gets committed and before. You can write tests that click through and are checking HTML that gets rendered because we need something to render it.
But to do that, you have to get your developers to write tests and has anyone had success in writing, like, satisfactory coverage of driver tests? Everyone should be saying no. In fact, we shouldn’t have a ton of them. They should be at the top of the testing period. Maybe a few dozen. They take a long time to run, they break a lot, they’re impossible to debug. We didn’t want to put that onus on developers. We knew we needed it.
How can we get runtime information and enumerate all the different paths or interface so that no screen has a problem on it? That happens every day, when people are developer, we decided to find their issues and report them on their screen in realtime.
Now, there are tools that do this, the Axe plugin does this, 10 and I/O does this. They have to install a plugin and install an extension and click a button and that one moment of clicking a button is the thing that keeps these testers from being run.
So, we decided to run it all the time. We decided to run Axe, all the time, under the hood, while our developers are working. We thought it would be easy. The testers these testing platforms were not built to be run realtime while 100 other things are happening on the screen. We ran into problems of timing, so, some of the rules took 750 milliseconds. We were looking at DOM mutations. We were grinding to a halt. We had to step back and refactor some of these rules, get them down into a sub10millisecond range.
So, what does it look like for a developer?
What a developer sees, on their page, is a giant, red box that overlays the element that has a violation. It’s not just a red box. It is a red box that renders that element inaccessible to them. They can’t click on. They can’t proceed. We wanted to bring that moment of in accessibility forefront and make it visceral, like, if someone in the world can’t use this element, you can’t use it. If you want to develop this thing and want to get on with your day, you got to fix this.
How many people are cringing and thinking, “this would never work in my organization.”
With buyin. I think it would definitely work. We had people we had buyin from and the moment we opened it up, people were like, what are you doing? You’re ruining my day.
How does it feel?
Yes! Which is exactly what I said. What’s more important? That your day is free of obstructions and abstraction or interruptions or that our user’s day is free of obstructions, abstractions and interruptions?
We also had to get zero with this. I don’t think, given our current approach, we could have introduced this on Facebook yet because there are way too many violations. It would have blocked people from doing important work, fixing, you know, bugs that were causes wide outages. We couldn’t turn this on and say everybody’s blocked until everything’s fixed. We had another moment to introduce this with a small developer community and grow it.
What we’ve seen is that the number of issues that we catch in production† because we’re running this on a small subset of production to see what the violation count is. The number of errors we see is† we see violations spiking because we’re just counting views. Then when you look at† or in development time, when you look at the user’s view, we don’t see them. We’re catching them, we’re getting folks to fix these problems. This, to me, is the ultimate launchblocking. It isn’t happening in the continuing integration where we’re running it on a sandbox server, it is in front of the world.
And our goal for this is to get to zero accessible issues with these roles. Like, not a single unlabeled element, not a single button, not a single grid cell outside of the grid. And we think we can do it.
So, the is, like† this has been for a week or two and we’ve got a ton of work to do to get it to the point where we can make it available. Don’t Tweet this. We are looking to make this available to the world and agnostic to the test runner. You may have testing in your organization, you may reter. That shouldn’t be the thing that makes or breaks the tool.
But the problem we have to solve going forward is how do you introduce this on a website that has thousands of violations? So that’s the problem we’re going to try to solve for the rest of the year and make it easier to roll it out.
All right. So, let’s have a discussion† in the time we have left† about continuous integration and testing.
You can tell me why this is impossible and it’ll never work.
Hi. So, I’m very, very interested in the tooling. That tool looks amazing. One thing that my team is doing† we were like that way on linting with different aspects. For instance, like, recently, we decided that we wanted to code more reactive so we brought in linters. We did [Indiscernible] each time we decided to change the roles, there’s a lot of brokenness. We decide, oh, we want to do† we want to change a role, especially if it’s more restricted, I was wondering how can we make it easier for developers to fix the rules, if possible?
Has anyone, here, done work with [Indiscernible]? A little bit?
I inherited† I inherited a repository that had a lot of bad decisions made and then all those people quick because of the inability to maintain the bad decisions, right? And so we came around and retrofitted as best we could. There was I mean, the lint fixed a lot of good work but at the end of the day, there was a lot of scripted, find/replace, find and flag, that kind of stuff. And, the† I mean, for a boutique purpose, it wasn’t too hard to write regular expressions. The problem was the layers.
Like, we had to do, like, four passes because you can’t just, like, all right, in one straight go, we’re going to get this to the other side. It was like going back for several surgeries to get to your goal.
I had an intern† I gave this intern the task of labeling all the icon buttons in Facebook and we could do this because we had the name of the icon and we could mostly map that to a humanreadable string from those cases, except maybe previous next and up, down, left, right. What we were able to do is find all the instances using something like lint and write a script that pulled out that pattern and put in the new pattern and using that method, you can write a script that can update in one go. We were able to label 800 buttons in about a week.
So, to pile on to that question, then, what is your level of trust† because you can use the test cases. This was ultimately why, like, regular expression was a blessing and a curse, when we did this, is you can get to a certain level of trust and you run a tool and you end up where a gigantic div and how do you feel at that end of that experience, trusting that tool, I guess or did you still really finetoothcomb that?
We had pretty good test coverage. We have an engineering culture that understands we need to make big changes like this and that we tolerate some of it. Teams know that code bots are happening all across all the codebases and if their test coverage† I broke the† this was terrible. I broke the checkin button for emergencies. I was testing my code and I left the string, null, in there and that got shipped. It was, like, 1 in 1,000 changes. For three or four hours, you couldn’t say you were okay. Things happen. I learned to be much more careful about checking.
But at the end of the day, if we’re not taking these momentary risks, we’re left with a long string of old patterns. So, yeah, I† my heart races when I press that shift button.
MARCY SUTTON: I was going to add, when you were talking about getting tools that are, like, really blocking launch and that sort of, like, knowing that people are going to resist it, I was going to mention that when I worked on Angular, we were adding accessibility things to a lot of the console and people were really mad and they would turn it off and they petition to turn things off. So, it seems like having an environment where you can control that narrative a little more and get that buyin is really important.
People will say, I’m building a game and it doesn’t matter. Actually, accessibility does matter in games. Besides the point that with the ability to turns things off and change it, that is often when it’ll fall down. So, that’s so cool that you have buyin because that’s how you can, like, kind of push your weight around a little bit and say, no, really, your job is to make this accessible.
Yeah. We talk a lot about friction. There is low friction and an easy to fix problem will get fixed most of the time. With accessible, low friction means it probably isn’t going to get addressed. It might be because of education or folks don’t understand. By bringing it in and making it visceral, we’re taking that highfriction and giving it to this developer. They can commit this code, but we can chase it back to who committed it and then ask them, like, why was this a decision that you made? Why did you feel like it was, one, okay to interrupt your colleague’s work and to interrupt our users interaction with this website? So, I’m all about letting people make the bad decision as long as we know who did it, we can ask why. Over time, we can dig in.
Can you expand a little bit on how you built or how the engineering culture was built to buy into† I’m going to call them governance bots, as well as the whole structure you’re speaking to. I love these ideas and I think I could get buyin for people to do it. There is that component of culture and the restrictions within organizations. If you’re only delivering on that, it can be more difficult to get that buyin.
There’s some buyin. I’m willing† and I† this is such, like† I’m willing to get fired over this. If I create such a ruckus, to get fired. Because I feel like getting fired for making things accessible [Inaudible] and I’m willing to do that. So, some of it is buyin, some of it is me saying, this is the line and I’m going to hold this line until a director tells me to stop and if that happens, then a huge conversation’s going to happen on Facebook.
No one has said that yet. And I keep pushing and I keep, like, getting in people’s faces. I don’t want to slow down our work. I don’t want to put friction† like, adding a label is a simple fix. Changing a role is a simple fix. If it’s more complicated than that, if we have to think about how to design a toast on the web so an element sliding up is accessible, I’m† we have to talk to a designer, it’s a process. For stuff that isn’t a process and the decision’s clear, the documentation is clear, I’m totally willing to step in with a highfriction intervention.
In terms of buyin, if this conversation isn’t happening at this session, I highlyrecommend the one about development and design because as these tools land and they move away from our engineering interventions, we’re shifting to design and we’re telling our designers, your developers are going to be thrashed by these tools. They’re going to get this interface and feel like it’s broken. If you preempt that, they’ll never see it.
I’m on the same lines as toast. I was wondering your experience with this flagging more complicated UI patterns, like let’s say you need a searchable. You can’t use the normal select element. You have to build it with a bunch of underlying layers and it’ll catch that you’re going off the rails here. My experience, you could kind of do two things, you could pass the linting roles and it’s not going to work with any screen reader at all because it’s a design thing. You have to wrap your head around all the semantics and which ones are supported by which screen readers.
Is this as effective as pulling the situations out? Like, we need to think about this control in a higher level way?
How do we know a dropdown’s working? That sort of thing† how are we doing on time?
MARCY SUTTON: We’re waiting for lunch to arrive, so keep going.
The way we’ve done this† this is a place where I think web tests do work. We updates the PHP webdriver so you can now send key commands that don’t involve a click. It used to mean it would click that thing, first, because the assumption was you were sending it to a text input. The focus command would click on it to focus it. We updated that a year ago. You can send keys now† just send key commands. And we introduce some methods. There’s a method for tab two and it’ll try to get there. When it gets to 200 tabs, it’ll fail. We have exercises, behavior exercises for our web. We’ve got exercises for select, dropdown, radio, we staged a component, run these exercises, create the file, create the web driver test and then run the exercise over the check box and if it passes, you’re good. It checks for labels and key commands.
So, we’ve† when I talk before about that space between custom code and component code, our solutions are different. For custom code, we’re looking at† we don’t know what the intent is. For the component space, we can write pretty simple libraries and then apply them so that if a component developer† or even a product developer needs to slip their behavior into it, we can have a conversation about why that isn’t the right design.
So, that’s a little higher touch. That was something the accessibility engineering team did, specifically, as a project. When web teams come to us and say, we’re building the 12 component library Facebook. Great, as long as these tests pass, I don’t care. Build it however you want.
MARCY SUTTON: We’re killing time until lunch.
I actually have a question, because where I work, like, the way we get things through is to do a blocking process. When you get from the warning level to the blocking level, how long did it take from when you started to make that switch and what did it take to work on that?
When we looked at the graph before of the incidents of errors, there were some rules down in the 10s and 20s, we fixed those. For the label and some of the rules that produce roles, I don’t want to change them to errors on the web side because there’s so much† I’m going to call it the blue side, not the updated side. We don’t have a mechanism for catching incorrect decisions. Once we have that, I’m okay with flipping those to error because we’ll catch the developer who wrapped a button in a button, because he put a super high friction in it. With a warning, they can still ignore it, which is not the best, but at least it’s not† we’re not forcing it.
But on the new site, we’ve been using typing to really restrict the flow of components through the system and what types of components we can pass to containers and that reduces the potential for custom code to get through and there’s a reduced potential for a lint error to produce the wrong outcome if we force them to make a decision.
So, I think it really comes down to your culture. We have thousands of developers, plugging away every day. If you have dozens, you may be able to flip all the rules up to error. Or you can monitor every instance that runs through, through some sort of, like, app where you get notified. All of this depends on your situation, how much time do they have to do checking and validation of what they’re doing? We have almost zero chance of doing that effectively so we have to† we can only [Indiscernible].
For custom code verses your component libraries, linting rules, ensuring that progressions don’t go in, I was curious how, screen reader testing factored into [Indiscernible] if it does, at this point, especially the angle of which ones these support? Like, do you look at other support?
We have a trained team that manually tests critical flows and they do this, I think, weekly, the critical flows. So, we do† we never get away from having folks click through because the† there’s always a human element and combination and even if we can verify that there’s a string present in the code, can’t validate the string, expresses it correctly. We have the humans testing only the highest value and not creating tasks for a missing label. The task should be, label exists and it should be better. It button says, add friend. It should say the name of the friend you’re adding so you don’t get into person’s name, add friend.
Yeah, so we still have that. But they’ve gotten so much better because they’ve been able to focus on, like, really dig down into the weeds of almost design. They’re not wasting their time on small stuff.
[Away from mic].
MARCY SUTTON: I was going to add about choosing which assistive technologies to support. I think there’s a bit of analytics. You could look at which browsers users are going to and picking a screen reader combination that works with that, but also user testing and an accessibility page where users can tell you, hey, this is not a good experience. Like, make it easy for them to give you feedback and poll users and test with them. It’s inward and outward communication and testing.
[Away from mic] so, we just started, like, doing more user testing and that kicked off a bunch of issues with components and we had a shock of† the downshift library for dropdowns. We had dropdowns that were keyboard accessible, but not screen readers. We were thinking about the process of, like, okay, user testing caught that. That was really unexpected to have it just fall flat, as soon as the screen reader. So, [Away from mic].
MARCY SUTTON: That was the downshift library. Did you find any issues?
We looked at trying to get back into the main library, but it ended up, like, no, it doesn’t fit in the API.
MARCY SUTTON: I know with some of those open source projects, the people who are making them are very open to fixing issues once they’re made aware of them. The lack of user testing in open source is kind of a known problem and so collectively, we can be filing issues, especially if you know how to fix it, that would really help because then every consumer will benefit from getting those fixes in.
So, yeah, I think we can probably wrapup and hang out, eat lunch. Eat lunch† whatever lunch happens to arrive.
Thank you so much, Jesse.
Afternoon Schedule Announcements
MARCY SUTTON: Okay. All right. We’re going to take a few minutes just to go through the schedule and make sure that everything is going to be a success, so, yeah, and maybe just take a few more minutes and then we’ll start going through the schedule.
All right. Well, we might as well get started. Okay, so, afternoon session. How was the morning session, by the way? Awesome! I loved the one I was in. So, for the afternoon sessions, we have quite a few things to choose from, so I want to go through them and make sure that we have someone at least to guide the discussion for each of those sessions. Around 4:00, we’re going to regroup in here and do a bit of a recap for what we learned and we have giveaways for that. It would really help† since you can’t be in more than one place at one time, to recap discussions you’re in so we can hear what was in there, what you got out of it and then kind of our favorites of the day, collectively. We have some swag and giveaways.
So, let’s go through† I’ll go through each one. Partnership between developers and designers, we have a leader for that session.
The last session we were in, in this room, that came up.
At 2:10, the five rookie engineering accessibility mistakes.
Popular UX and UI accessibility.
Designing for the extremes, that was Joanna. She might be up there.
Accessible Maps Discussion? Cool! At least, if you have questions, you know, people can come in and we can, you know, facilitate that discussion and it’s really just, like, questions and answers.
Interviewing and Supporting people with Disabilities in the Interview Process. So, we want to make sure that, you know, at least people with questions and some answers can be present. I will be in a different session at that time. I think the intent is to learn and discuss how to remove barriers in the interview process for people with disabilities. So, do we have anyone that wants to go to that?
I have something to say. So, when I proposed that this morning, I think I wasn’t articulating it really† the way I was emitting it. So, it seems like a little bit more [Away from mic] my intention was interview. So, I don’t know if they’re interested in more of the job aspect [Away from mic].
MARCY SUTTON: Yeah. Okay. I think we could get value out of any of those. So, if people have strong feelings, either way, we could do a user testing. Is that sounding like what people are more interested in? Would you be a facilitator of the conversation? I can update the schedule to reflect what the topic will be about.
Accessibility Case Studies, do we have a leader for that or people with case studies? All we need is one. Any case studies?
Okay. We got a taker.
Probably some great case studies from Starbucks.
This is meant to be a discussion and so we can all pitch in and collaborate on this stuff.
Okay. So, 2:10, More Inclusive Web accessibility. Do we have a leader for that one? Anyone.
I think that was Chris.
What’s the concept?
MARCY SUTTON: I think going the full distance is what I would anticipate. A lot of times, we can get pretty far for accessibility, but maybe it’s not truly including everyone, so that’s one interpretation.
[Away from mic].
MARCY SUTTON: Selfvoicing thing? Okay. Well, that one’s at 2:10, so if he’s still around, I would go† if he’s here somewhere† I think we have an hour to figure it out.
Making a Business Case for Accessibility. That is at 3:10.
That was Joanna.
MARCY SUTTON: Accessibility Event Registration Pages. I believe that was Mark? Hopefully he wants to go to that. I will go to that one, as well, since that would be good information.
Microsoft Accessibility Insights Demo. It is really, really cool tool. So that would be a good one.
And Accessibility Seattle Meetup Organizers, I will be at that one.
Then we have Testing Tools and Process for Accessible. It could be about what tools are working for you, really anything. We need someone to kind of facilitate that conversation. So, any volunteers? Awesome.
And then, we have open time after that, for Accessibility Hacking. If you have time to kill, getting home on a problem, there’s a web accessibility Slack that I can link in the slide deck or the resources doc later. But I would think of the Accessibility Hacking track is an inreallife example of what we do in Slack, which is ask questions, collaborate, get help on projects. That’s a time to get help on things.
We will regroup, in this room, at 4:00, with recaps and prizes and we will go forward and conquer the world. Okay?
Let’s go find our places to our different rooms and, thank you for listening.
Partnership Between Developers and Designers for Accessibility
All right. Well, welcome. Welcome back from the sunshine. I’m glad everybody got themselves back inside and just wanted to start off with an introduction. I’m Jessica and I’m a UX designer at BECU, a local credit union here. This is my pair, here.
I’m Casey, software developer.
We pair in almost everything we do so when we decided we wanted to come, we decided we would be brave and pair our bravery to present, full disclosure, I’ve never been to an unconference, so I didn’t know what I’m getting into, but it seemed welcoming and accessible.
One of the items that did get dropped off of our title is we’re talking about just getting started. If you’re really invested in super technical pieces, this probably wouldn’t be the talk for you. But what we want to talk about is our partnership and we have paired in our journey and really what we see as working well, our challenges and we want to foster a really good conversation amongst everybody about how do we facilitate pairing and how do we really work and bridge that divide when you have someone who’s untechnical, such as myself, trying to give requirements and user journeys in such a way that can be incorrectly interpreted.
So, we’re going to talk about that.
Feel free to ask questions because I’m better at answering questions than sometimes presenting.
Yes. Agreed. And we don’t have any slides, so you’ll just see the agenda.
I’ll keep looking up there.
If you can’t see that we’re not presenting anything†
If it’s distracting, we can turn it off.
I think it’s fine.
Just to kind of start out with the context of experience, I’m a UX designer. We buy solutions and implement them. A lot of our work has been with configuration and what do we need to customize and we’re starting this evolution† it started about two years ago† where we wanted to embark on building our own software from the ground up. With that, comes a whole host of complexities that as an organization, we haven’t navigated before.
The project we started on was a proof of concept saying could we build a mortgage point of sale system that would replicate that same guided experience you get when you talk to a loan officer? We have an existing solution that’s a vendor solution.
And so we started out, really not being experts in anything but in our own experience. And, the† the environment, three years ago, was really when we were starting to realize that accessibility was a thing and I know that’s† as we talk about everything else. You’re like, oh, my word, how did we get to that space of ignorance? Wanting to address that. So, doing the right thing and serving our members is just core to the foundation.
As we began to publicize accessibility and talk about, hey, we need to make sure our stuff is accessibility, it was never a hard sell. So, it was always† the harder part has been figuring out how. Everybody was like, yes. How do we do it? We branched out on this journey. When we started building the new frontend for the mortgage piece, we had a product owner who came from mortgage who had never built digital properties before. As we were trying to prioritize the user stories, they didn’t understand. They agreed that accessibility was important, but they didn’t know how to articulate what they wanted and then myself, as a new UX designer, this was the first project where we were building it from scratch.
We had one acceptance criteria which was “make it accessible.” That was my first introduction. What do I do to take something we partially started building?
I wrote that story. Make it accessible.
I think that’s why we started pairing because it was like, what does that mean? What does accessibility mean? And sitting down and figuring out, like, why we’re doing it and understanding the need, as well as saying, okay, well, I can do it based on what I see from, you know† based off of websites. But is it helping with the full user experience all around? So that was definitely a beginning of our accessibility journey.
The piece that was really cool† and I don’t know if this echoes the experience any of you have had, as a designer, it was really helpful when Casey would ask me a question. That was too generic. Okay. I tried again. Make it keyboard accessible. Is that accessible enough?
Yeah. So the pieces† what we began to do, we began to go out on a journey for an inventory of the things we didn’t know. At that point, we were just so novice. We needed to have a more finite list of what, specifically, did we need to know.
Some of the things that we’ve done is pairing together to look to identify training materials and as I find something I’m like, oh, this is really cool. Hey, Casey, I saw code in it. I told him Jesse’s session was really cool, there was code in it.
There was a snippet and she would say, can we do this? Yeah, we can try it. I feel like what got us† our whole team got onboard is she kept sending out video tutorials and we were all stressed because we had to get this coding down and finally, I think it was one point where she was like, no, we’re putting in a spike into† a sprint and everybody’s going to go through this training and I think that was a great thing to do to try to push us because I think a lot of† including myself, a lot of our team members didn’t quite see why we need to do this and, yeah, no, I think you’ve been a big component of that.
Can you talk about the emotions of yourself and the team, like before you overcame this learning curve and then after?
I know there were some points where I emotionally cried at work because I was so frustrated. I couldn’t articulate what we needed to do and this idea, like, we’re blocking people out. Kind of makes me tear up now because I’ve started volunteering with disabled veterans and teaching them how to curl and you become more of an advocate as you develop those personal relationships.
I’m a UX designer, I’m good at storytelling so I started leveraging the stories. We’re making it so they can curl on ice. You can make the site work. This isn’t that hard, I don’t think. I don’t know how to do it, but I’m assuming it’s not that hard.
We started to see that emotional piece of realizing it was powerful to cry at work. No, I really care and you need to care. It wasn’t that you didn’t care. Casey cared, that’s why he’s my partner, my favorite developer I’ve worked with. What was it like when I was telling you, make things accessible?
It would drive me nuts. I feel like, at the beginning, it was like pulling teeth because, all right, we have all these XYZ things we have to do. It was the realization that, you know, I want everybody to use our site. Like, I want everybody to have access to it and realizing that I’m excluding someone or some people because I’m not thinking about these different things that, you know, that I† I take for granted, you know, was a big turning point for that.
I think it was definitely a harder learning curve, which became a bit of a challenge for me like, was just, like, trying to get everybody on the same page and wanting to do things or to do it. But I feel like once we got into it and realized, like, you know, it’s not as painful. There’s a lot of things you can think about, then it was kind of less of a frustration or challenge. I think I was going somewhere, but the end.
So that’s where we found ourselves, so one of things we did is we pushed to get an external audit done of the property we were building. We talked to our product owner, our IT† and everybody agreed, especially as we talked. This is going to block us from going live because we an agreement that we will not release properties with accessibility issues. We said, let’s get ahead of this and do an audit. We were trying to do it. We had a big challenge of trying to get leaders introduced into the environments we were working in.
If you’re just getting started, pushing for an external audits extremely helpful so you can work against the punch list. Having the punch list, getting that feedback, now I get it from my developers, but getting that from an external side† if you’re a developer and you’re in the room and you’re working with a newer UX designer, pushing back with those questions of “how should this work” was really helpful. I know how it should work, I just wasn’t articulating it and so we found this really powerful, often times, we’ll sit together and I’ll be sitting there, watching Casey code and say, okay, is that how it’s supposed to work and listening to the screen reader and, okay, does that make sense? Kind of like what you talked about earlier, does that make sense? Working very closely together. We’re co-located in the same room.
If you’re a developer, really don’t† don’t shy away from asking for more specificity and more details because it pushes the designer to think through how is this supposed to work?
The other thing we did† I was like, this is good, I learned a lot. Carving out that time, specifically, in a sprint where everybody’s going to take this training. I was the defective product owner. Don’t be afraid to do a power grab. Fundamentally, when you’re standing up for the right thing, we didn’t find any pushback because we were able to articulate why this was important, why this was taking time and see the payoff on the other end as our deliverables became faster.
The final thing† we’ve made list and we’re documenting everything we’re learning and sharing, but we’ve reached out to our membership and been able to curate a group of our members who are able to come in and help us do usability tests. Maybe this is just† I learned a thing and everybody knew it. We were really seeing a difference between something being accessible and something being usable with† for somebody who’s using accessibility tools and there’s a big difference because we had some stuff that passed fine. It even passed from our external audit but when we brought users in and said, hey, we want you to use this. This was working with mobile check deposits, even though it was accessibility, it wasn’t usable. That’s been able to do different cycles.
If you’re a UX designer, get those videos collated down to a digestible piece. Because then when I’m able to get those to my engineer, they’re like, oh, I see. You are able to [Indiscernible] the video of the user’s interaction of the site.
Casey, did you have anything else you wanted to talk about or tips or how you got me to give you the things you needed?
Versus making it accessible?
The thing I really liked, we had her on our team, like, just there. Like, I literally could throw a piece of paper at her, if I needed to, to get questions answered. We had† we were able to be in the same areas. There was a lack of turnaround time. Maybe that was our process. That was a big win for sharing for accessibility.
The one thing I do want to try to do† and I don’t know if this is something we can do. We were talking about guidelines and stuff for, you know, logos and how our inputs and stuff should look like. I was thinking it would be cool if we could do our own basic framework that has a lot of that stuff that we need in place, combined with, like† we don’t have any automated testing for a lot of basic† you know, did you put the right semantic headings on? I feel like those things, in the future, hopefully we do with pairing is coming up with a universal guide for our teams across the company, that we could use for accessibility.
So, enough about us. We really wanted to hear from everybody else. And so, we’re just curious. Everybody had to start at one point. If it was yesterday or 10 years ago, when you started to get involved in and aware of making sure what you’re building is accessibility, do you have key takeaways? Key struggles? Similarities to our journeys? Anybody want to share about your starting point? Because everybody’s got to start somewhere.
I want to share my situation, but also wonder if anyone has tips. So, I’m a frontend developer. And, we collaborate and I’m more† like, the accessibility question from†
My first experience started, I was in customer experience, not UX, I got to handle the calls when people couldn’t use their digital properties. If you want to have something that will break your heart, trying to justify why you can’t fix something makes you passionate about fixing it.
I’m not a designer, there’s certain things that I can point out, like, hey, this doesn’t have the right color contrast, here’s an alternative. But if it’s something like, I don’t know, autoscrolling carousel that’s a problem, I’m like, this is a problem. I can’t do anything better and then† do you have any tips for articulating† I’m not a designer, I can’t give an alternative and have it be collaborative that way, but how do you communicate in the opposite direction.
I ask “why” a lot. You know, why are we doing this? What’s the benefit of this carousel, as an example? Usually, they have an idea from there and then a lot of times, if you can’t† for me, if I can’t get that push out of the way, I push for “let’s test it.” If you say this is adequate and this will work, let’s put your money where your mouth’s at. I don’t know if that works at all companies. For me, that’s what I have been doing.
One of the things† one of the things that I also like to do is for me, creativity comes from constraints. If you can say it’s this attribute, this is the problem and how can we take this and solve within this constraint, I would imagine the designers should respond positively to that. If I know the box of what’s possible, it’s a lot easier to be more creative.
I was just going to say, I’m in a similar situation on our team where I’m the accessibility expert and I’m the frontend dev and I often get designs that come down that are simply† if not impossible, but extremely hard to make accessible. And my approach has been to try to offer solutions where I can, like your color contrast example. And also to provide resources for them to learn why the thing they want me to do is hard to make accessible or why it’s [Indiscernible] usability and not just for accessibility feasibility, but for all users, like infinite scroll and how infinite scroll can lead to fatigue for users who are sighted and use a mouse.
It’s really difficult for engineers, especially because sometimes we have to wait until the very, very end of the design process before we can give feedback, especially at a big company, like sometimes the design will be back and forth in our UX department for a month before it gets to me and I’m like, wait a minute! What about accessibility and they’re like, it’s too late. We just have to do it.
So, I would be interested to hear what resources you give to designers, to developers, to help them educate themselves.
We recently introduced a metaphor to our designers that I find really helps them think about this problem, cursor-based interactions, that abstracts away from accessibility. We don’t even talk about accessibility. I bring over a Netflix remote and say, how is this going to work? If you’re sitting on your couch knowing this design’s on the TV and you need to move around and interact with it. And that often gets them really far along in thinking about a cursorbased interaction.
And you haven’t said the word “accessibility” yet.
Has anybody had a tool that’s been really helpful, that you’ve used as a designer?
One thing that, if you use, that can help with the color contrast stuff is there are† for a lot of things, there is a lot of, like, really easytouse tools stuff for that. The color contrast tool where you can put in the foreground and background color and it’ll tell you whether or not you’ll pass the different types of standards you would need. So, I’ve been trying to provide as much stuff like that to the designers and the developers on my team because none of them care about accessibility. So, it’s really cool to hear about people like you, who are taking charge and it’s actually working. In my little corner, it looks very bleak for accessibility. Little tools like that, here’s something where it’s like, you have to show it in a way. Hey, look, it’s so easy, I’m not inconveniencing you.
I also kind of have a question for you guys. If you† if you knew then what you know now, since you were† you have this perspective of I want to make this happen, I don’t really know how to start. So knowing what you know now, what would you do differently in getting going?
So, the first thing† the first thing I would do is approach that earlier. We were thrown into start building the thing and that spike that we did† we actually watched† it’s a free course. You probably watched it. It’s on Udacity. I watched all the lessons and tried to do the exercises. You can turn it in and it’ll tell you the right answers. I was like, oh, look, the right answer!
That was really helpful because it started to give me the right language so then I would go, oh, this is a solution where we should use an ARIA tag and this is how I understand those tags to work. As I looked at the guidelines and their examples of solutions, I started to understand more what it was† what it was suggesting. So, this is an href. A lot of these things, I didn’t know these terms so it was hard for me to communicate to the developers when I didn’t know† I think I have it still written on my whiteboard, programatically expressed semantics.
That was my chance to look smart and don’t ask a question.
It happens a lot.
What is she talking about?
But that definitely helped. And then I had a chance† I’m in the master’s program at UW, so I had a chance to take an inclusive design course and through that, they had us do a challenge and work with† I found a friend of mine who has MS and he graciously volunteered. I traded him, minuteforminute for childcare. It helped to build a ton of empathy for myself. Even doing an exercise like that, I don’t endorse trying to pretend. Find somebody who’s willing to help you and doing that helps give that language and that storytelling, as well. Because people really do connect to the story. It’s your role to make that connection.
I had a powerful moment last week. I was talking to the members of a mobile team. I looked around and it was a super diverse group and I realized, hey, it’s unfortunate that throughout the history of our country, marginalized groups have turned to location to address this. This is our chance to stand up for stuff we believe in. It’s like, hey, we’re on a mission. This is the area we control. These are the assets we build, that we create and we can start to right the wrongs if we take it on as a mission. It kind of galvanized the team. It’s the constant storytelling and the success stories and highlighting the successes when something becomes more accessible.
I would definitely encourage the designers. The other piece, too, when Casey let me sit and watch him code and explained what he was doing, I† as a designer, we’re curious, we’re always researching. That made me super excited about it, too. I was thinking back to your question about the carousel, even inviting the designer to watch the challenge of how would we do this, that can be really helpful, too, because it’s breaking down those silos of, like, back in the day, I say, make it happen. It’s all computer magic.
I definitely have to say, pairing and sitting down and talking through and doing stories together definitely was a big one for both of us growing.
The other thing, because we had a lot of people on the team. I really think showing someone why it’s worth it, as well as if we go do, like, user testing on something, even if it’s just a wire frame. Having the depths there to take note said and track people’s discussions, kind of gives you an eye OPENER of, oh, you are building something and thought it would work well with XYZ. That was a big seller. If you have people higher up in the company that aren’t onboard, that should be something to do is put them in that position to say, okay, you know, here’s† here are the people† that are your bread and butter, your community, this is what’s happening and to see that, I think, is really what makes it worth the want to do it, if that makes sense. At least in my experience.
Do you have a question?
So, there are, like† as you mentioned, lowhanging fruit and things that are very obviously designcenter, the education that I received was really lacking in expanding on that. So, I’m very aware of, like, color contrast and readability issues and stuff like that. And then the talk this morning, you were talking about buttons and list items and that pretty more clearly from the developer side of accessibility. But, I’m curious to hear, from you guys, if you had any issues in the mortgage app or anybody else in the room, about where maybe, like, the middle ground. Like, what can I do, as a designer, to support my developers? And things that I might not be as aware of as, like, color contrast and readability?
So, one of the big pieces that I [Indiscernible] is thinking about the navigation order and trying to think about the site as if it was an outline of a report you were going to write and how does the sign posting go? How should somebody be able to go top to bottom, if I made my whole design linear, what does that order look like? That’s been helpful. I was going to write this out as an outline for a book I’m going to write, it would just be in bullet point lists. That’s been helpful.
And then the other piece is† again, we have a very small team, very colocated. When I’m looking at a new feature or component I want to do, I bring the developers into my sketching sessions and have them come look at it and hopefully they’ll highlight early or propose alternatives before I get married to something that’s going to be hard to code.
I try to remain really, really open, like hold my designs very loosely for how are you going to implement it? If nobody’s using it, who wants the fancy pixels on it? I want people to interact with what I have. So I try to hold them loosely so if I get that feedback or pushback of, hey, can we do it differently? Yeah, let’s collaborate and colocate. I didn’t in tend to make this hard to do. I want to make it easy to develop and easy to use. So, those have been helpful.
But then, taking that more technical training and immersing yourself, it will give you the language and it makes it easier to read the resources out there, once you get that decoder† I would agree, like, the education that I got, as a designer, was woefully lacking because it is more of a technical side. I might have been doing some frontend web development. But mine was on the user research and the imagery. So, that was helpful.
Or, you just get† learn in class that you have to put something in the alt equals for images and that’s your†
I agree on the same bucket. I think the biggest thing goes back to the whole collaboration, is that, you know, sometimes when you’re developing something, you have in your mind exactly how you want to build it. You know how to make CSS look slightly more usable or pretty. But having the conversation, even when you’re sketching the designs and stuff of thinking, okay, well what does that really mean? We got a header here and there’s going to be a list, which is a little box, and how do we maybe† we’re going to have to nest another list in it so how does that look as a structural design?
Conversations, having that communication and understanding the context, together, so that when you’re doing these user stories and building all this stuff out, you have that there. The other thing is, is I sometimes get a little frustrated with screen readers because I try to predict what it does or doesn’t. I just kind of shut off my CSS stuff and look at the beautiful HTML as it is.
How everybody intended it to not look like and look at it and say, okay, what is this structure? Is this structure comprehensible enough for me to understand what we’re looking at? So, I just kind of piggyback off of what you’re saying.
Thank you, guys, for the questions.
Could you talk more about the design language that has evolved? Perhaps the artifacts that go into sketch files to express what the behavior should be and how much of that gets done in interpersonal communication and presented in a design?
So, a lot of it is just interpersonal and that works as long as there’s real immediacy from when design is done and Casey’s coding it.
This goes to our maturity curve. At the beginning, it was all the interpersonal communication and now, what I started to do is to be more articulate in creating wire flow diagrams of, okay, this is here and it’s going to go to here and starting to add in, specifically, of I think this is going to be problematic. This is what I intend the screen reader to do. You have to ask terribly intrusive questions. We call them the highlyoffensive questions. I had users swear. I had 10 users in a row drop F bombs in the survey. I’m like, it’s the government.
Trump made me do it!
It’s not my fault. But, it ended up to this nested check boxes and government’s saying I have to make† digitize their paper form that’s poorly laid out. The compliance is like, you have no room to move. Nobody understands the paper copy. We don’t care. It’s the law. Working through that† I forgot what your question was. The design language and what I do. So, now knowing that that tab order was going to be problematic, I went through and in addition to my “here’s the final red lines so you know how the layout should look.” I also layered it, this is the tab order, this is how you should be able to navigate through it and putting that level of specificity so I made two documents. Here’s the ones without red line markup and here’s where I’m telling you specifically what I intend for the interactions to do.
I’m really big in imitating fine art.
I do think with, you know, our goal to have and sort of similarity between different groups and teams with design, it’ll help with that. What she does do† and she doesn’t really realize that she’s done it. We’ve gotten to the point where we have a user story where we have certain things that are built constantly and they’ll be coded† you’ll have copy/pasted code that you’ll need to add and it’s a reminder of, oh, yeah, don’t forget, this has got to go in there, too, when you build it. Most of it is interpersonal. We’re starting to go more into it.
Even if I’m bloody wrong, if I put code in there† how dare you! Example of code and in sinuate I should copy/paste it. They’ll take ownership to do it better. This is very poorly written, I can improve upon it. Great!
We were doing an indeterminant spin and it was coded to do an alert to tell you things were changing. We were looking at that and I’m like, I’m not sure if that’s how we should do it. A few of the devs classes sat down and said, I think this is a little abrupt. It gives you a reminder of things you can talk about. If I was going to take away anything from this, building that communication with your designer, vice versa and trying to get everybody to see opinions.
And the last piece I wanted to ask the group† because it’s come to my head. The one challenge I have as a researcher and designer, I can’t accessibilitytest my prototypes. I can’t test it at all, even if I build it out interactive, that comes out a hot mess. But a screen reader on it, it would be horrible! And so, I am looking for a way to try to catch, like, things† especially usability issues. It doesn’t make sense if you’re not looking at a visual presentation on the screen.
Does anybody have any tools. I’d hate to find it so close to launch and say, hey, we’ve really screwed up. I can test† so, I was just curious if anybody has anything. It’s a problem I’ve gotten.
So, we can†
[Multiple people speaking at once].
He’s got a kickstarter thing. It’s this ring that can tell colors and we think it might be able to depict shapes and text and so we’re thinking, like, that you might be able to use with a paper printout to have somebody scan over it, to just give you an idea. We don’t know. We don’t know if that project’s going to [Away from mic].
It’s really far out there.
I was just going to say, I will say that, like, for our team, we have an accessibility expert, that’s dev, that will† weekly meetings with the designer team so what you’re designing isn’t going to be lastminute. We caught this quick and you have to change this now. It’s interesting to hear the disconnect that’s happening there’s connect between developers and designers. When we do hire designers, the accessibility expert that is a dev will be part of the interviews and you’re going to be testing accessibility and seeing how much they know about it, about the design before you hire them, which I think is really cool because you have designers that are† they want to make things accessible.
And I will say, so, part of my work at my job is I’m a prototyper, so I’m in between dev and I help design prototype and we prototype it as an accessible thing and if it works, dev takes the code and makes it work on the backend. It is another resource we had to add to help with that. But it did† you know, it helps, like, less dev time figuring out those problems and less remediation. We did† it’s a new job that came up.
No, that’s really powerful, too, because if you can catch and address those before it’s all the way down. Halt. Halt. Can’t go forward.
I think we’re† we have two minutes. Any burning questions?
Well, thank you, guys. You’ve been so gracious. This was our first time doing this. Very delightful. So, thank you.
5 Rookie Accessibility Engineering Mistakes
Do you guys mind if I start one minute early? I’m too nervous to sit here.
Hi, my name is Sophia Allen. I’m a fullstack engineer. I’ve been working on accessibility for about two years.
And, when I first started, I knew pretty much nothing about accessibility, other than you want alt text on your images. That was about it. I was given† for one of my first tasks† basically an entire application and told, okay, your job is to make it accessible.
And, so, I had a really steep learning curve about what does it mean to make something accessible? Where do we draw the line between accessible, not accessible and how much development does it take to get you there, especially when you’ve working with a legacy software.
So, I wanted to share some of my five biggest, like, things that I thought were true, that I since learned were not quite correct and just be† part of why I’m doing this is because when I make a mistake, as an accessibility engineer, I often feel really bad about myself. Right? I feel like I’ve failed my users that are depending on me to provide access to the content. I want to be really radical in exposing the mistakes I’ve made and make it okay to make mistakes and talk about them because we’re learning, right?
If you find one of my mistakes, matches along with some you’ve done, give me some snaps. That would do a lot for my selfesteem. If you have mistakes I have not mentioned in here, I would love to talk about those, share resources for ways you overcome your mistakes and build a small community of accessibility rookies here. I’ve been doing it for two years, I still very much feel like a rookie and people say, hey, you’re our expert, tell us what to do. I’ll try to figure something out.
And some things, I just don’t know.
So, my first step is acronyms to know, just because when I started, I didn’t know any of these. Before my talks about accessibility, I like to spell them out. First is ARIA, this is the accessible rich internet applications. I’m going to talk more specifically about ARIA and things I’ve learned about it in a moment.
WCAG are the Web Content Accessibility Guidelines. These are what we’re assessed on when we say what is accessible and what is not accessible. AT is assistive technologies. I’m trying to train myself not to say screen readers. Our users are not just using screen readers. They’re using a variety of different technologies to get to our content.
DOM, no one told me what the DOM was. It’s the document object model. For people who are not devs, it’s all the HTML on our page.
Okay. So, first one, accessible’s easy! I’ll just use Aria attributes. Um†
Yeah! So, I had to make something accessible. I say, make accessible tab interface. There’s ARIA attributes. Not quite. So, ARIA is an API and equivalent to CSS, it controls the rendered auditory or nonvisual.
We do this by adding attributes to HTML, as many of us know already. So, in my code example, I’ve got a div. I make it look like a button by applying a CSS class of button. I can make that sound like a button by applying the ARIA role of button to that attribute.
A lot of you may have done this. When you try to use it with any assistive technology, this is not sufficient to make this divan accessible button. ARIA is here to fill in the gaps, where HTML cannot help us, where other technologies cannot help us. Right?
And, at the very top of the ARIA principles guide, it says no ARIA is better than bad ARIA. You start wondering, what is bad ARIA? When they shove 15 attributes on to one element, which I have seen. The top two ways I’ve seen ARIA have bad consequences are, first of all, broken promises. When you apply a role to something, you are making a promise to your users that that element will behave in a particular way. Assistive tech is not going to do all the work for you.
For example, when I apply button to a div, it sounds like a button, but it doesn’t mean I can click on it. If you see something that looks like a button, you expect when you click on it, something will happen on the page. If you are using assistive tech, you’re going to expect clicking on it will do something. So, I’m just going to quick† go back to my last slide. I need to listen not just for clicks on this div, I need to listen for keyboard interaction to fulfill that promise that that button will act like a button for users who are not using a mouse.
The second biggest way that I’ve seen ARIA misused I know there’s one outstanding bug on my team about this. It can accidentally destroy meaning and hide content if you apply it in the wrong place. So, for example, if I have a link and I want to provide an accessible label to it, maybe the link wraps something that would make sense to a sighted user, but not to a user who’s using. I might apply an ARIA label to it. The label will wipe out any meaningful content inside of the thing that it’s on.
So, for example, we have label here, the ARIA will be read† read out. The actual content of that link will not be read. I’ve seen this a lot on headers, like, if you have a clickable header that will expand a section. If you put an ARIA label of “click to expand,” they’ll hear “click to expand,” but not your section.
Second, using the code examples from the ARIA authoring guide as standards. So, again, if you’re like me, you are Googling, okay, how do I use it correctly? I’m going to follow this combo box, select, autocorrect. You probably don’t read the intro, you go straight to the code.
And so you copy the code, you translate it into your framework. You feel really good. Yeah, I made this accessible! Well, again, there’s a gotcha here, which is that, again, from the ARIA authoring principles, testing assistive technology interruptibility is essential. The authoring guide is a guide, it is not a guarantee. Right. It’s a demonstration of how you could use them, it’s not necessarily that you should make them that way or that it makes sense for your specific use case.
Not only that, if you’ve done crossscreen reader testing before, you may have learned that not all assistive tech, not all screen readers, themselves, support all ARIA attributes and they don’t support them in the same way. ARIA Controls is an example. I believe JAWS supports.
So, it’s really essential to test it across multiple screen readers or whatever screen readers your company support, before you take those ARIA examples as your gold standard. Just because the guide says you can do this, it doesn’t mean it’ll be memorized. It’s trying to match native software usability with keyboard commands and reading order.
So, for example, in a tree, I use arrow keys to go up and down. Space bar to expand and collapse. If you’re a user that doesn’t have a lot of experience using keyboard navigation, you might not know those shortcuts. You might get confused.
So, it’s really important to do a lot of usability testing.
So, my advice to you, when you’re trying to use the ARIA guide to drive your development is to read the actual guide, not just the code snippets. Use HTML where you can. Remember, this is spackle. You want to fill in as much of the gaps as we can with ARIA, but it’s important to have a solid foundation of HTML before you throw ARIA into the game.
Read the rules. There are specific standards about what can go where. If you have a menu, it needs to have menu items inside of it. That sort of stuff. There’s some great I things out there that will hash ARIA breaking things for you, so I encourage you to go out, find those and include them in your practice, as an accessibility developer.
I see a question?
What was the name?
I think it was ESLint, plugin, and Axe, the web plugin and Axe Core has ARIA validation built into it for you.
So, yes, please check those out.
So, you tried ARIA, you tried the guide and you’re finding that it doesn’t always do what you want and you read a great article about, hey, HTML is accessible by default. Just use HTML. Yeah. And you get into all these great arguments with other developers about what’s a button and what’s not a button and all this great stuff.
Important conversations to have, but still. HTML5 is not a magic wand. I once saw a tree component that was a semantic list and it had list items in it and you could expand and collapse it. Perfect HTML. Completely keyboard inaccessible. So, unless your page is completely static, you will at least need to do some keyboard support. Buttons that are semantic buttons will help you with that. If you’re building a custom widget, like a tree, that’s not going to be enough.
Secondly, you also need to remember, we’re not only building for assistive tech and screen readers. You also need to consider† sorry. Color contrast. You need to consider, are we breaking up our text in logical ways? Is the order of things on our page, does it make sense? And, is the content, itself, meaningful?
The last thing that surprised me in this† when I was trying to use HTML instead of ARIA, is getting users out of content is almost just as important as getting them in. You need to get them past the 10,000 links to the helpful stuff in your footer. If you’ve got a navigation bar with 1,000 controls in it, you need a way to get them past those controls to your main content. And these are things that take some design and thought more than just plain HTML.
So, my approach, since learning this, has been to be more thoughtful about where and how I’m using my HTML elements. We do have those arguments, is this nav or menu or button or link? I believe these are healthy arguments that are making my page cleaner and my apps more accessible.
We need to provide focus management, color contrast and consider more than just assistive tech when we’re trying to include as many users as we can and really pay attention to your content. Do labels inside your buttons make sense? Are they helpful? Do our links† can you predict what will happen when you click on a link? Right.
So, at this point, you’re feeling pretty good about your UI, but now you need to test it, right? So, what I did is I installed Chrome Box. I was like, this is my screen reader, I’m going to test with it. Aahh! Don’t do that! I also had, like, half a dozen accessibility plugins, like Axe, that were really helpful. But, there are some† like† gotchas here. Automated accessibility tests are great. They find buttons without labels, incorrectlylabeled ARIA, but they don’t catch the larger functional or integration issues. You do still need to have someone, at some point, go into the screen reader, turn off their mouse, interact with your app the way one of your users would, to try to test your accessibility. Right?
Also, emulators. Funkify is really cool. Emulators are wonderful for building empathy, but they are not intended, nor should they be used as development tools or certification tools. We don’t want to promise to our boss that something is accessible because I can use it while Funkify is turned on.
When we talk about more effective accessibility testing, first of all, yes, please, learn how to use a real screen reader. Like, go to the web survey that they do every year and they will tell you what the most popular combinations are. I have personally started using NVDA and Firefox. I know it’s overwhelming to use a screen reader for the first time. So, what I recommend is you go to the Web Aim Accessibility Testing. They have instructions on how to use it with a Mac, Firefox and JAWS. I found the NVDA documents really intimidating when I was first trying to use that screen reader.
Test at multiple levels. Absolutely use linters and accessibility checkers and functional tests. My team has ones that, for the more complex components we build, we write tests for that. Our auto complete has one. Usability testing. Preferably with users. It will not interact with the page the same way a blind user would.
Not all screen reader users will use your page the same way, either. It’s important to include all the variety of people that we’re trying to build our app to support.
And now, you start to feel a little bit overwhelmed, right, and you know this is†
And you go, wait, do I really have to do this and then someone gives you a carousel and says, hey, make this accessible. Making this accessible is important and it’s all on me. That, I’m here to tell you, is a mistake. And, when I’m still working with my team to fix. Really, accessibility is a team sport. So, it’s not† if you wait until code† until developers are going to implement a feature, you are almost guaranteeing yourself a hard time for making something accessible, even with the best, most empathetic, most interested and accessibility developer on your team, they’re going to have a hard time making a carousel accessible.
So, first up, prioritization and time. When your project managers and owners are creating user stories and thinking about what features they want to build, are they including users with disabilities? Are they making this a priority with your team and giving you time to educate yourselves about accessibility? Are they giving you time in your sprint to address issues and to do the extra work for your components to make them accessible?
Second is the design process. Are you practicing inclusive design? Are your designers are thinking about disabilities when they are building up their wire frames? Are they talking to your developers to know how hard it would be to make something accessible? Hopefully you’re as lucky as me to go listen to that.
Third is your content. There’s a big CMS behind the app I’m working on and I can try to provide alt text if authors write it. If they don’t, I can’t add it to the image. Do your videos have transcripts? Do you get alt text from your authors? Do your button labels make sense?
And last is testing. Do your testers know how to use a screen reader? Are they† do they know you need to tab two things, not just click on it with a mouse? What are the different use cases that they are testing when they are testing your features?
So, stepping back, my four big takeaways here are use HTML and ARIA thoughtfully. Neither of them, alone, is going to be enough to make your app accessible. You’re going to need both and it’s going to take time and thought and effort to use them correctly.
Test at multiple layers, don’t run your Axe plugin once and call it good.
Think about the different areas where you need to test so that you’ve got as much coverage as you possibly can and as much confidence you can.
Include accessibility as early in the process as you can. We have all seen this where a feature† we all know it’s way easier to make a feature accessible from the start than it is from taking something that was designed and implemented inaccessibly and hack it and make it accessible.
Last, give yourself permission to make mistakes. For a lot of us, this is going to be an iterative process where our first attempt is going to be better than nothing, right? But, when a user gets it, they might have a problem with it and that’s okay. So, we’re going to take that feedback, we’re going to improve and learn more and make it better with time.
For me, I want to share a couple things that have helped me to learn more. One is this great blog/component library out there. Maybe you’ve seen it. It’s called inclusivecomponents.design. And it goes through the common patterns, like a card. What does it mean to code a card? How would you write that up in HTML? What kind of ARIA attributes? Or a tab panel, what is the† how do you do that well?
The other thing that I do a lot of is try to connect with the accessibility community. I do a lot of following people on Twitter because there’s often, like, a today, I learned, you can’t use ARIA on a header. So, follow† Devon, I’m following you on Twitter. And Marcy and everybody else’s talk I go to.
And the Accessibility Seattle Slack is great to. I encourage you to check that out and ask questions there and pay attention to questions other people are asking. Even if it’s not relevant to you, now, it may be relevant to you in the future.
So, I just wanted to say thank you for coming and open the floor up to anybody who wants to share some of their new mistakes or resources they’ve found really helpful when trying to learn more about accessibility.
I wanted to share three mistakes. One that I’m most embarrassed about, I told them they could put as much in alt text as they want. I told them to put all of the email text in there and then I used it with a screen reader.
For the longest time, I heard that a hover state of buttons didn’t need to have a strong visual contrast ratio because you move your mouse away. But, WCAG says† I think 2.1 is when they added to darken it. I never understood why until somebody showed me using a screen magnifier. You zoom it to 500%. If it gets lower contrast, it makes it harder to read. And the last thing is very similar, [Away from mic] nobody understand why until using the magnification.
I have a question to your response, which is, what do you use instead of Tool Tips, like, as an alternative? We have a lot of stuff that gets truncated so we’ve been using Tool Tips.
I think the biggest issue is on the hover, because if you’re using† if it’s a large Tool Tip, you need to move the mouse to move your view away from it and hover’s gone.
But in general, you can build it in UI again. [Away from mic].
I found that a lot of times when I’ve been asked to build a tool tip, it’s because they’re trying to get out of showing a content button. We have a previous and our next. Our teachers are trying to go forwards and backwards and had no idea what the carets meant. Let’s make a tool tip that says, move to the previous resource or the presentation.
Please, can we put the word “previous” in there? We have text in the button and the tool tip at the same time, which is super annoying.
I’m still complaining about that. But, yeah, I found sometimes if you have something that is difficult to make accessible, like, they want you to bill a tool tip, pushback and say, hey, why do we need a tool tip in the first place? Is there another way we could do this that would be easy to implement and accessible by default, or as close as we can get?
I have a mistake I was going to share. The fact that there are times when you don’t use alt text for images when they’re presentational. That was not a thing you had to do.
My question was† and I think there was somebody who did actually talk about this already, but I was presenting so I didn’t get to see it. When you’re at a smaller agency, I know the best thing is to have actual users who use screen readers test your stuff but you aren’t going to be allowed to do that. Is there an alternative to doing automatic things? Do you have any other thoughts on that or what to do [Away from mic] it’s not up to me, it’s not up to my budget. What else can you do? What do you see?
I heard some advice, earlier today, which I think is great. Even at my company, we’re a pretty big company. Sometimes we don’t have budget, framework or audit. So, providing a link for your actual users to give you feedback is super important. If you could put your accessibility link at the bottom or a feedback form saying “how are we doing?” “What are things you’re experiencing?” Feedback is as real as you can get. Making your best effort and providing them a way to tell you when they think you need to improve.
I think there’s also some groups out there, I think. UW has a Center for HumanCentered Design. I’ve heard maybe they do usability testing help. But, I haven’t really followedthrough on that yet.
Did I see another hand out there?
So, I was working on something recently and I feel like I probably did make a rookie mistake or am about to†
† which is form that you submit it and then, like, 800 milliseconds later, it gives a success state or a failure state. And I was looking at the ARIA attribute and I put it on there because I thought, well, when this new state comes up, it will notify the user, you know, like, without interrupting what they’re currently reading. Is that right or is there a better way to handle a case like there where you have a loading state and a notification, like, your form was successfully submitted?
So, this is one of those areas where I don’t feel the expert. My approach, lately, has been to use an alert. If you put role of alert on your form validator, it will tell them you typed in a number in something we expect to be a string. I think ARIA sounds like another reasonable way.
I was just going to say, a lot of times for the validation, like the one thing that a lot of people miss is, like, instead of doing a failure state is, just letting the actual input types do the failure state for you. So, like, if something is required and they left it blank, let the input flow its own flag. If it’s supposed to be a number, don’t type in text.
And I actually, like, I went to a workshop once where they actually used ARIA for the success state. She’s more of an expert so she might say, no, don’t do that.
I’ll give the microphone to her.
DEVON PERSING: I have two answers† oh, God. I have two answers. One is, it depends.
My usual answer. Sometimes, ARIA can sometimes be weird. Some screen readers ignore them if the container or attribute isn’t on the pageonpage mode. Depending on how you’re making that update, it might not register. So, usually a way that’s really straightforward, usually, is to just move focus to that new content, either the success message or there’s an error, maybe error summary. You might want to focus to the beginning of the form so someone can go back and fix their mistakes.
But you submit a form, it finds errors, it reloads the form with a summary message at the top that says, hey, you missed these things. If the focus is there, you can go through the form and then having individual error messages on the fields that have problems is the way to go. It kind of depends on how your form’s being submitted and how your page is updating.
Sometimes it is a little bit more predictable, as far as what† what a person needs to do next, if they have to go back and fix stuff. So, it depends.
I can share one thing I learned, which is that I always assumed icons were for presentation only and so in my app, I went through and made all of our icons role equals presentation. Sometimes those icons carry meeting and they’re not just cute and they are helpful. So, for example, we have a little calendar icon next to the date that something has been added to your teaching calendar. It’s helpful to know that that date is not the assignment date, it is the teaching schedule date. Right? So, I’ve been trying to reflect on when I make assumptions about what I think is presentation and what is not presentation, as someone who’s sighted, to way back† try to give the benefit of the doubt to they want to hear it rather than I don’t think they should have to care. And, am I making this role presentation because it’s easy for me or is it really unnecessary and distracting to their experience?
So, that is a TIL for me, label. Give your icons meaningful labels.
DEVON PERSING: One way to† we’ve been kind of handling when to do that in our design system is having major and minor icons and we’re not always 100% consistent with that. A major icon is presented with a heading. A minor might mean something different. It’s not always† in general, we’re trying to figure out ways, this type of icon, you want to have text. If you have find patterns, you can start internal logic around [Inaudible].
So, I’ll snitch on myself. All of my first experiences with accessibility were all Devon’s problem.
Because we were at Expedia. So, some new mistakes that I made, that, like, I know were all past, but tell your friends, you did all these great classes for us. This is what you’re getting into, this is why, this is how we’re going to judge you at the end. And in increments, we would internalize that knowledge and then go try and do it. And so, the first thing we did is we basically added keyboard support to our clickable divs. And then, we were, like, yeah, aren’t you proud of us? And they were not proud.
And that was a lot of time and effort, too. That was a pretty significant chunk of that sprint and then we completely missed the mark. So then they were very patient and polite. And then buttons and tags and interactive things. So, we went through and we put all those in there and we felt real good and then our designer’s like, all these blue boxes around everything. Now that it’s keyboard navigable, I have these focus outlines. I’m just passionate about being helpful and I offered up, we can use CSS to turn that stuff off.
And then Devon was mad at me again.
So the moral of the story is, like, make sure that when people think about it, they have an allin attitude towards making something that they already know is accessible. Because, yeah, half measures and incremental approaches are a great way do waste a lot of time and you’re going to end with up the same thing in the end anyways.
DEVON PERSING: I would say there’s some incremental things that make sense. Like, it might make sense to focus on keyboard accessibility for a sprint. Don’t make keyboard accessible and then turn off focus. My main teaching tool is gentle shame.
Speaking of clickable divs, I always regret having built this angular directive, which is a little attribute you can apply to your component that was a clickable div. It would give it role equals button and keyboard support and I was so proud of it when I first made it and then absolutely horrified at how people were using it and so I’ve since killed it and have been better off for it ever since. Clickable divs are a constant struggle.
One mistake that I’ve been making, that I just found out was a mistake is that just because I can use it on a keyboard doesn’t mean it would pass keyboard usability. I’ve recently discovered† people who are used to ATs are accustomed to certain things and sometimes I’ve written stuff that will be counterintuitive to that, like being able to use the space bar for a radio, how that works out? I’m not sure. Definitely, like, something to be mindful and something I’m trying to work on and understand, what’s the expected behavior of an element. I have no idea how it’s supposed to work so I can say it actually works on a keyboard and a keyboard user can say, I can’t use this. That’s all.
Reminds me of an ARIA role is a promise. When you apply role of radio button, then you need to follow the rules for a radio button [Away from mic].
Does anyone have learning resources that they’ve used that have helped them or helped them overcome these mistakes or help them realize they were making this mistake?
MARCY SUTTON: Love this conversation. So, yeah, we don’t all know† we’re not born knowing accessibility. You have to fumble your way through. I test patterns and look at what the native thing does or a plain HTML file and often, that will help me understand, like, okay, what is the browser doing if, for some reason, I need to create a custom thing, so I can learn what those expected interactions are.
I also really like the ARIA authoring practices guide because they show you and how to implement them in terms of, you know, navigation, expectations, semantics and all that stuff.
It’s not always perfect, so sometimes, you know, if you find something awry, it is open source, so go contribute. That way of, you know, having a collection of accessible patterns means that designers don’t have to go reinvent the wheel a lot of times and I’ll recommend looking at those to see, oh, if we tweak our pattern slightly, it’s much more conventional and users know what to expect and so sometimes, I don’t know, it’s this originality versus convention, like designer skill, I need to create new patterns entirely, for some reason.
I think if you can say how much that will really cost you to build and maintain, you can kind of talk them off that ledge a little bit.
Most of the developer docs, I think, are really great. Because they’re, you know, maintained a lot and they recommend good patterns. Even just seeing what† what’s the default of browsers, like, what do I need to add to a set of radio buttons to make sure they’re grouped appropriately? I’m a senior engineer and I look up the docs quite frequently. And that’s okay, it’s part of the job is knowing, oh, I can use an HTML element to its full potential if I go read up on it a little bit. That’s okay. We can do that.
So, yeah. I can’t think of any other resources. There’s some learning materials, like, there’s a web accessibility course from Udacity from the Google team. You can get free accessibility training.
Yeah. Those are resources.
I’ll share one kind of cool feature that I learned about, like, as soon as I learned about ARIA and the authoring practices and the sometimes spotty compatibility. [Away from mic] there’s a public W3C working group that is called aria/at, they make attributes to see if this is going to work with JAWS and everything else, so I think that’s a cool feature.
I think we’re out of time. Thanks, everyone, for coming. And I’m happy to chat with anyone after.
Popular UX/UI Patterns and Accessibility
Hello, everyone. My name is Matsuko.
So, I propose this talk for the discussion I was envisioning because, for me, examples of things they want to build or ideas about things and sometimes I think about, is it actually accessible? So, I have a couple examples of things we can look at and anyone else in the audience that has some points to make, that would be very welcome.
So, the first thing was this pattern ware, the header, when you scroll down, it initially is on. And when you scroll up again, it is there again.
For me, I feel like it’s annoying it’s popping in and out and it’s going up and down.
I wanted to show†
For people who are easilydistracted, it is easy to forget it’s there. I work as a user experience analyst. I think distractibility is one thing and people might leave what they’re doing and come back and say, what was I doing? That’s one thing for that, for sure.
This one, in particular, when it’s up there, they actually put it on the CSS so it appears on the menu. If they didn’t do that, I think it would have been fine, actually.
Does anyone else have any thoughts about this.
I have a question. I’ve always wondered about this particular pattern.
DEVON PERSING: I’m wrangling.
I’ve always wondered about this particular pattern, like, why?
For me, it’s rationale. It’s very tall, so they want to not obstruct so much content and when you’re scrolling down, for example, it’s an article, they could focus on the actual content better. But I feel like this popping in and out is more distracting for me, personally, rather than if it just stayed there.
I meant how to scroll up on the web page and you can go back
Did you mean† wow! Sorry.
Did you mean† did you mean you’re wondering why you have this pattern?
With this pattern, what is the benefit of having this thing that does magic?
I just like it.
That, I know.
I can give a design reason. So, one actually impact on a site that is showing up in a lot of search results and a block content site, like Medium, you will impact and lower balance rates because it gives people another way out of the page that isn’t the back way. They come back up and go, oh, there’s more of this site to explore versus having to scroll all the way back†
Can I say what you said back to you to make sure I understand what you meant? Hiding the menu keeps people there so they don’t bounce as often. Is that what you meant?
It’s more around† I think you were talking about if you positioned fixed. The point is to make sure when they’re thinking about leaving the page, the option to not leave the page and go check out other content is available versus hidden.
You’re trying to say, they should be able to leave to other places that are on the site or the site map? At first, I thought you were saying we’re trapping them there is a dark pattern. No, that’s not what you meant.
It’s a toxic SEO.
If you want to keep things available when people want them, you can pin to the top always and people won’t have to guess where to find them again.
DEVON PERSING: I have a counterpoint at the top of the screen. If you resize the text, something that’s fixed position, it can often take up way more space than you think. It is common for people with low vision to bump up the text size. It can make it difficult to read the main content.
I think we passed this one around. You can run around that way.
DEVON PERSING: That’s a great idea!
My question for the room, for the other specialists in the room, would be, can we give hews for where the menu is if we take it away? We fix it for the reasons Devon pointed out and here’s the sign for you to go back to the menu?
I don’t know if it’s still this way, but Intercom’s blog had a cool menu, when you scrolled down, it shrunk into this little thing. But that was a way† they kept it fixed at the top, but it went from tall to little sliver, but still had, some, like, key indicators. It would be their blog. They hype their blog. Yeah.
Maybe Google will†
Okay. Yeah, they redesigned it. It had a smooth animation where it took the stack and but it sidebyside, but the heading always stuck around.
Using a break point to resize elements to reposition them.
DEVON PERSING: We watched for something amazing to happen.
Are we okay in here?
But that’s a solution I’ve seen, is to compress and not expand.
Did you want to go on to the next example?
I’ve seen the hamburger menus. If the font size [Away from mic].
I saw some faces, as soon as she said the word “hamburger.” Devon, did you pass something?
DEVON PERSING: It depends.
I think that† I think many people here might know this, but hamburgers can be confusing. If the word “menu” doesn’t appear, people can be confused. It’s not that hamburgers are not all equal, you should do careful research in your UI that they have conversions.
So, my next thing I was thinking about† which I couldn’t find a good live example of this, is a worstcase scenario. In this example, we had no hints from the content or labels or anything to figure out what these are supposed to do.
And the keyboard controls, you can tab into radio set and use arrow keys to select them and for check boxes, when you use tab, it goes through each check box and tab for each button. If you can’t tell† looking at this, they all look like buttons. Some of them are check boxes and some are radios. We skipped two buttons for some reason.
I don’t know why. Keep going.
So, this is kind of a worstcase scenario.
My general advice is: Don’t make things look like other things. It’s [Away from mic].
Thank you. Thank you. But we can’t always avoid that. There are certain okay situations where you might want to turn a link into a calltoactionstyle button thing. But, I basically tell people to try to avoid it until they have bled out every other option and then they should beg for forgiveness when they do it.
Did anyone have anything else on this? I’m sure we all have hot takes.
I agree. I was wondering what is it that tips this over to make it look like a button? Because to me, they all do look like buttons. They could easily look like a form element if the text was† the place for the text was much lighter or the outline was much lighter. So what is it that you’ve done, here, that is causing the accessibility problem?
I think that depends on the style and the context of these kinds of controls. The UI of a given website would dictate what a user expects. Buttons look a certain way, in a certain domain. If you have buttons things that look like your buttons, but are not your buttons, the user will be very confused about how do use those. Thing about a screen reader who can see, but is hearing prompts. They would think, based on sight, that the control would work one way but then they’re being told another thing. They might think it was built wrong and they would be very sad.
Did that answer your question or did I make it worse?
No, that answered my question. It became obvious to me after I asked it. I thought there was something going on with the functionality, but it’s more of the looks.
The looks with the expected behavior of something.
I couldn’t find a very good example. This one is sort of what I was talking about, links, but they’re buttons and this is also maybe check boxes. I’m not really sure. I tried to use keyboard animations, but it doesn’t seem to work at all.
So, yeah, I think if you’re trying to make accessible check boxes on radio inputs, they should have some sort of circle there and the check boxes should have a squareshaped thing. If this is a check box, then it doesn’t look like a check box.
Those cats are really cute though.
Okay. So, I guess the third thing is forms with labels that are placeholders or labels that go up. And this form is, I think, one of the worst examples. I think they just have placeholders here. So, you start typing, you follow the whole form. Then you don’t remember anything you filled out, what it was.
So, placeholders are bad.
That’s the summary of my take. I can be here for three more hours. Just ask, I’ll regale you for a long time. For people who are lowvision, who are distracted, that’s a nightmare. We need labels that tell us what to do and how. We could use ARIA for further instructions, if we have to. That’s really all I have to say about that. I think that’s pretty obvious. But I welcome questions on why we don’t like placeholders.
Just to add on here, we’ve recently been doing research with lowtech literacy populations around the world, folks that come from backgrounds that haven’t enabled them to acquire the tech skills we have today. We’re talking about folks who might not even know what a button is on the screen and, like, how to press it. And we find that, with forms like this, like the more you deviate from the standard form, the faster the literacy goes down and to me, a form is there to convert. It’s there to, like, get information and do something and the moment you [Inaudible] you have lost millions of people and the more you deviate† if you want to talk to your business people or designers and say every deviation is a loss of revenue.
We should be developing for people who could be easily lost or might have disabilities so I think this pattern is popular in the interest of being clever and saving vertical space, but that’s not really a good reason to do anything. I love you all, I promise, but we need to think about what the users want to do.
Going back to the placeholder issue and the comment about lowtech literacy users. One other problem with placeholders is that user who are not familiar with this pattern mistaken it for text already in the field and will try to erase it. I have. I have watched my grandma struggle with this pattern and I sat there and wondered how long she would spend trying to delete that text and it was a long time.
I had a user say, there’s nothing to do here, all of the inputs are filled out already.
She ended up thinking it was broken because she couldn’t delete the text to type what she wanted to type in the fields.
There are lots of specialist bodies who recommend we don’t use it. We will provide the link after we are done here. Just don’t do it. Just say no to placeholders.
I was going to ask you about the exact placeholder that’s on this, when you click on it, it goes up to the border. I’m curious as to whether that’s better or still bad or something else?
So, I think this has the same issue as the previous ones where it looks like it’s fine in the layout. It goes up, but the label gets really small, too. Do you have anymore†
What you said. And also, the size of the floating label is a big one. Also, there’s distraction because people might be confused by the animation happening. You would need to basically have the option of opting out of the animations. So, again, why do this when it’s five times more code than just putting a label next to a thing and calling it good? If there are a designer opinions, I would love to hear them. I don’t think I’m always right, I think I just love being right.
I’m in a personal hell where I have to keep styling this shit.
You feel handcuffed?
I’m not Google so I didn’t build this so it’s hard to build it as a firstyear frontend div.
Basically, again, just don’t. In my opinion. I’m one person.
DEVON PERSING: It kills me that they made the placeholder text darker because that’s an argument I have with developers all the time. Why don’t we make the contrast higher? No, no. The borders are really low contrast.
I can see you getting†
Sorry about the aggression.
That’s okay. We’re all hanging out together.
DEVON PERSING: The mad lib style. I’m arguing with someone about those again.
Another thought about this one is the form label is also overlaying on the input so if you have a longer label, it could not fit in the input space that’s given. Probably the label should not be [Inaudible] anyways, especially if it’s a usercreated kind of form, then it could totally happen.
Yes, or translated.
I can’t see this, but I’ve read this several times so I’m just going to have to go from memory. This is comfort reading for me. I go back and I’m soothed by this particular article. I’m only partially kidding. So, I can’t digest this. These are bad for all the reasons I’ve said. So, don’t listen to me. But, these things can be distracting, they’re hard to code, they are confusing to people who want to do patterns that they’re particular with, like Jesse pointed out in her research. If you want to dig into why these are bad, read this.
A friend of mine, Eric, has a Just Don’t Do This article. You can Google him, Google it or I will find it for you.
In the back, we have a question, comment, concern, criticism?
Placeholder hate going on right now. Is there any†
In form field, is there any other context in which placeholders might be useful or is it just all† it’s all that†
From a tech perspective, placeholders don’t behave reliably between screen readers. The AT does not agree on how they work and what they should communicate to people. We have pretty common ideas of how labels work, which is why we should have descriptive labels or descriptive text. Does that answer your question?
I think so. I’m trying to think of† there’s stuff where channeling this doesn’t work, but this might make sense from a design or usability use case. I was trying to think of some. I couldn’t think of any.
I’m going to say bold and say I can’t think of a placeholder would be better than a label.
They can sometimes be okay†
We have one question back here.
I wanted to followup on what you were asking. What would be patterns that would be used to either signify what the user formatting should be, that would be better than placeholder, because that would be one of the things that it’s used for. The other one is something that’s coming to mind, that’s not ideal, but would help the user input the correct thing and prevent further errors. That’s not [Inaudible].
Yeah. We have the ability, as developers, to add descriptions to inputs with ARIA. It can be near the input and can be above or below it. You would use the right IDs to say† let’s say your validation code is a sixdigit number, separated by dashes. Masking can be very, very confusing to people using keyboards or screen readers only. Masking is the idea that the browser will not allow I to enter text it doesn’t want you to have. If you’re using a date picker, it won’t let you enter the letter Z, because it’s not† ZIP code is numbers only. A mask would prevent you from entering letters. The user wants to know why the thing they think they should do does not appear, which might make them think their keyboard is broken.
I use the format things with placeholders before and I also used ARIA and I think that can sort of work if you can make a placeholder high enough in the contrast.
Yours is a combination of that?
Yeah. Phone number, the placeholder would be parenthesis, XXX, parenthesis, XXX and the ARIA described by would be along the lines of three numbers, three numbers, four numbers.
Or a string that it gives what was described.
I wouldn’t use parenthesis XXX. So, screen reader, you get a sentence. For the visual user, you have a placeholder.
It goes back to this could appear to be filled in. Test them with your users. In my personal advice, I just say don’t do it.
Just another thought about using placeholders is once you’ve started type nothing to the field, it’s gone. You’re lost again.
So, this image, it has a good example. There’s a label. There’s extra task that describes what’s in there and then there’s input.
DEVON PERSING: That helps with the pattern when someone’s using magnification, they’re not missing a hint under a field. Having all the instructions, before the field, is a good pattern in general.
Hi. To say something that’s bad about placeholders. One time, blind users, a page they can search things, but instead of having† like, there wasn’t a label and the placeholder said “search.” It’s an example that randomly changed every time you refreshed the page. It says Seattle or Giraffe. Oh, could you find this? They were trying to go around on the page and sometimes they get “Seattle.” They were actually very confused and they never found the search.
For any reason, if you’re going to use a placeholder, you should put an example [Inaudible].
DEVON PERSING: I love that example so much.
So, we could talk more about, like, the form labels. I’m not sure if anyone else in the audience has any other UI problems they were trying to discuss.
Watch your language!
I was just going to say, what patterns do you all hate the most.
Anything else we want to talk about? We can go on carousels for a few years.
Just a little bit curious, in mobile, where you see, like, a slide to submit or a prolong toggle kind of action. Your thoughts on that?
Can you give an example? Would you mind?
I’ve seen a button where instead of tapping on the button, if you know† your iPhone when you get a call and your screen’s locked, you have the slide to answer.
A very long toggle.
Yeah, but it becomes a very long toggle. I don’t know what the input’s called†
A toggle with a middle state† not a middle state, but a long delay. That pattern doesn’t exist on the web, to my knowledge.
DEVON PERSING: I’ve been seeing it.
Devon, don’t hurt my feelings.
It’s like the swipe to delete.
DEVON PERSING: It’s be absolutely sure you’re doing this or submit things as a “are you sure?” It’s a long† I don’t know what the control is, because it’s not†
I was wondering what you thought the semantics would be for that? For a keyboard user, there’s no slow, careful deliberate state. It would have to be A or B.
DEVON PERSING: If it were a native slider or a range slider, you would have to use the arrow keys or up and down gestures.
That sounds like a dark patterns for users. You would create like, maybe at minimum, five steps. For someone with low motor skills or it’s painful for them to use the keyboard, that’s a nightmare. So you should do A or B toggles and leave slides to mobile.
I saw someone over here and someone over there.
Very quick. I think a more accessible alternative is to put an input field and say, “type the word,” delete.”
This is just more on† I guess what I assume is the negative pattern, floating menus or feedback toys that show up on some websites. Is that accessible to anybody other than very central†
Do you mean, menus like the ones from beginning of the talk?
I’m thinking about the ones that float along with you, just in case you need them.
The ones that stick to your window when you scroll?
And how would you get to those from a keyboard.
Sorry, did I cut you off? Did you have more to say?
To my knowledge, those aren’t too bad because if the body text is long, the user can go back up to where they were and it wouldn’t be so bad. It would be terrible if you’re changing the order of the web pages if you’re doing it, which I don’t think most of them do. Does that answer your question?
Another pattern that shows up extensively, on a large social media site that’s blue, it’s called the hover card. Hover over someone’s name.
Oh, yeah. Oohhh.
Welcome to tool tip hell! How do you get into this? It is not a dialogue? It is not a tool tip. What is it?
How would someone discover that? Is there any data on how the user will find it?
It will pop up in focus. Where does your focus go in the next tab?
There’s no way to opt into it or out of it. Is that what the problem is?
DEVON PERSING: If you hover over someone’s user name, it’s the same thing. I don’t know who stole it from who.
It’s a nonhover dialogue. Contextual†
I’m just wondering if the solution† if we had to have† if someone that was a stakeholder, you have $1 million to keep this hover card, would the solution be to give a click interaction that would give the option to show the card? I think that would be okay, rather than discovering the hover. Do you have thoughts, Jesse, or someone else?
Long ago, we would have go to the link and enter. If you had opened it, the tab would open it. If you shift + tab back to it, it would close.
It all sounds messy. I wonder if the better pattern would be not to do this, which is what we say, I think, a lot of in this field.
Too many of me?
I’m not sure how to even take that.
On the many banes of my existence is Outlook† Outlook website† no, the Outlook in iOS, when you’re trying to schedule something, setting the time gives you a bar†
It does it in Windows, too. Because I stopped using it because I hated that.
It gives you this dial that you have to, like, flip through. But when you flick it, it goes like this, well past where you wanted it. And then scrolls the thing off the screen so you can’t move it back. It’s satanic. I don’t know what evil person made that thing, but†
Did you have any patterns you wanted to discuss that came to mind?
DEVON PERSING: Now that we’re all depressed together?
I have another one, but I was thinking about to the toggle one. Not the long toggle, but just a normal on/off toggle. It’s usually a check box, that’s styled like a toggle. And I’ve had experiences where users are trying to use it on a computer but because it’s a check box toggle, it didn’t work for them.
It’s like a dragging check box, it doesn’t do anything.
We have 10 minutes† never mind me. I wanted to ask, since we’re all depressed† if people have favorite wins that’s are really good or websites that do something cool that we can all talk about so we can all feel good.
No one has anything good to say about anywhere on the web?
You have one?
This is called†
By someone familiar.
This is Marcy’s blog.
You can come here for some happiness, I guess.
If anyone hasn’t tried it, there was a library called Dragon Drop. It is pretty fun to use. Yeah, that’s the one. So, that [Inaudible] it’s pretty cool.
I do have one negative. Travel sites, on the whole, just need to calm down.
I saw someone on Twitter say they go back to using regular forms until they can get things right. Do forms, A, B, C and then D. Travel sites, to my knowledge, get sued multiple times and remediate and then still have terrible things happen.
DEVON PERSING: Then they have to stop A/B testing.
Has anyone seen a travel site that has done something really cool or good? I saw a comment in the back, as well?
Not necessarily good or cool, but†
I used to work at Expedia, all the frontend devs got pretty decent at checking accessibility. There was a dedicated accessibility team in the company. So, it was something that was thought about. A lot of time, it was like, put on more duct tape. More duct tape. We’ll fix this. And, yes, they do A/B Test everything.
I felt like I just watched your soul leave your body.
Looking back, I’m like, what features did I build? It was mostly just A/B tests.
Something positive I’ve seen happening around frontend development, with accessibility, is these frameworks are pretty [Inaudible], especially in general, output. But it’s been good to see that, like, React or view components, that are widely used, have accessibility issues that are being addressed and they’re good, central ways to tackle, like, a calendar component in React and file an issue and get it resolved. I’ve been seeing that and that’s been pretty amazing.
Yeah, I think one thing that’s important to note, it’s what you do with them that can be either good or bad. They enforce paradigms that can make things bad. We can’t say React or Angular is the devil.
I went to Ember Con, and they are good about making things accessible.
That sounds like Jesse’s whole angle. Don’t let it go out the door.
I’m going to talk about a project I actually worked on. We recently rebuilt the careers part of starbucks.com. It’s all brandnew code. New content management system. React Static. We made the design a lot simpler. Granted, it doesn’t have the same kind of bells and whistles that a travel site did. Sometimes, just starting with design and saying, hey, do you need multiple nested menus there, really, can make a huge difference.
Anybody has feedback on it, I’d love to hear it.
I don’t think you’re started with design on that, you started with context and purpose. You started with the user, what are they trying to do? They’re trying to find the job. You started with the person, then you went to the content and design. If you start designing first, you have to know who you’re designing for.
I think that† I think we can all just start by asking questions about what we need to do with our websites. Sometimes people lose sight of the goals are. I always tell developers I’m training to turn off CSS and see what happens. While it’s almost always bad, but then they learn and if you can design something from the topdown with HTML, you’d be amazed at how different the outcome is for the UX. Did you have anymore patterns or anything you wanted to segue to? We have a few minutes left.
It’s just a silly one, but since you’re at the keyboard, if you go to github.com/voss/forms.
So, down in the bottomright, you can see this is probably not a good pattern. So, in the bottomright corner, we have the next version.
Al, do you accept feedback?
Oh, wait, just try this one. Random number generator.
I think you clicked and stopped it. It should keep going.
What happens, dare I ask, when I submit this?
Nothing. It’s not hooked up. I was just trying to get people to think about† you may have to reload the page to get that thing to actually fire up. Or maybe it’s mad at you.
I think we’re†
Anyway, you get the point. I don’t know why there’s [Inaudible] I thought that was it. Oh, no, there may be one more. Let’s see if there is. No.
Maybe it’s the browser.
I think it crashed your browser.
Doesn’t matter. You get the point.
One billion lines of HTML.
There we go.
Must be the click that broke it. Interesting.
You can change the URL to/form4.
It decided it doesn’t like me.
Oh, I don’t know. Never mind.
In the last two minutes that we have, I thought of things that are good. There is a repo of a device on how to style controls. If you Google his name and the word, GitHub, it will find him. He’s gone through every single native control and how much he can style and what the limitations are. It will change your life. Changed mine.
Again, we will be sharing some of these links later on†
I’ll find it later, I guess.
It’s hard for me to read from this angle. He has a repo at the top† not the very top. In the middle. No, up. You see the blue link that says “GitHub.io?” He goes through all the business of the form.
There’s the repo. You can find information on how to get very, very far with good, semantic accessible controls. So, we’re net positive. No more sadness.
DEVON PERSING: That was our last one of the day.
We’re free now.
DEVON PERSING: No. Not yet. Stick around a little bit. We’re going to† we’ll have everyone come back here. We’re going to do a little, sort of† almost like a retro and have people talk about things they were really excited about today and we’ll have some prizes, as well. Take a few minutes and come back here around 4:00, or a little after 4:00, and we’ll do that.
End of the Day Recap
DEVON PERSING: Before we start, I’ve got two brief announcements. Did someone lose a blue water bottle? It’s in the back.
If I gave you a key card and you didn’t give it back, please give it back so the university doesn’t come after me. Thank you.
MARCY SUTTON: Okay. So, let’s get this wrapup started.
How was everyone’s day?
[Applause and cheers].
I thought it was awesome.
So, to spread the knowledge around, one last time, we would like to go through each session, briefly, just to give some highlevel points, what you learned, either the person who lead the session can do it or someone who attended. Totally up to you. For each one, we’ll be like, hey, anyone want to say a few words?
We have some giveaways we’d like to do. We have TShirts that say friends don’t let friends shift inaccessible code. We have one small A11y cat shirt and socks, from Shopify, they are amazing. They have stargazing and mountains on them.
It’s the Polaris style guide.
MARCY SUTTON: We should get this going so we can go dream about this all night.
Anyone care to start us off with the Hearts and Mind session?
For me, I think various teams and companies can be difficult. One of my big takeaways is there are other people fighting that battle so I feel like I’ve got support. So, thank you.
MARCY SUTTON: If you would like to come get your swag.
Something else I want to add about that session, Jesse said she was willing to use her privilege to the point she was willing to get fired for this. Fighting for accessible so much that you’re willing to put your career on the line, welled up with emotion in the best way. Yes. Thank you.
So, for the next session, Getting People at Big Companies to Care about Accessibility.
It was very interesting to hear what people are doing at their companies and how different our, like, challenges they have to face. But I really like thinking that† talking into† through a way of thinking [Away from mic] I feel like they’re interesting and [Inaudible] you just need to know how to talk to them in their own terms and they maybe invite them to accessibility testing so they can see with their own eyes how people are actually struggling and that will change their mind and support you and you have them on your side, it will make a whole difference.
MARCY SUTTON: Awesome.
And, swag. Or, we can deliver it to you.
Qualitative Accessibility Testing. Who went to that session?
Yeah. So, we went there. It’s just like kind of like a roundtable conversations and we were just talking about [Away from mic] people who are not used to working with the communities, with disabilities, and so it’s just, like, soft skills to what’s the right way to talk and how do you accommodate in terms of testing.
So, some thoughts from the session was that, like, maybe some people are more comfortable doing testing in their own home environment because [Away from mic] et cetera.
MARCY SUTTON: Awesome. And, swag.
Making a Convention Accessible for 11,000. What were the takeaways?
DEVON PERSING: I see an arm. I see an arm!
Hello. I’m neither dev, nor a user research specialist. I do events and so, it was fun to see something that was sort of for me, that I could apply to my job and sort of learning from not necessarily their mistakes, but the things they have ran into, such as, like, the carpeting being too high. I would have never thought of that. Making an accessible space for everyone to enjoy, so that was really fun for me and other little things that I would have never thought about.
MARCY SUTTON: Wonderful.
Okay. Content, Context And code from the User Perspective.
This was my session and I learned from Al that you might not want to propose a session because you miss an awesome thing. I asked people to share with me, what† so, one thing I was kind of reminded of is kind of† the thing to remember is, the bowl tag and the metallic tag, I Code in HTML are [Away from mic] and they’re not read out by screen readers so you want to use a strong or [Away from mic]. DEVON PERSING: Love it. Practical tags.
MARCY SUTTON: It’s good to learn what’s actually learning and that little tidbit might be something that sticks with you for the whole year or your whole career. So, yeah, there is no bit too small, that’s worthwhile.
Distractibility and ADHD on the web. Who would like to talk about that one?
DEVON PERSING: The pink shirt is going.
MARCY SUTTON: Nice!
Who raised their hand?
Hello. During the talk for distractibility, we had a really great discussion. It was, like, infrastructure beginning and an open floor. What was great is, like, I† I love meeting with more people with ADHD and I got a ton of tools that I’m going to download. Just that collaboration space where we’re able to† like, this worked for me or this didn’t work for me. Invaluable information. Super great.
MARCY SUTTON: Another plug for the resources doc, if there were things you learned today, go out to that Google doc and we will know what those tools were.
Okay. So† oh, yeah, we’re not showing that computer. We’re showing this computer. I’m like, why is it not working?
Okay. So, afternoon schedule, Partnership Between Developers and Designers for Accessibility?
As a junior designer and someone entering the field, it was cool to learn about ways I can support my devs and my annotation and accessible design, not just from, like, the design side, but also from the dev side.
DEVON PERSING: Swag.
MARCY SUTTON: There’s another one.
This is just† could you plus the resources doc again, Marcy?
MARCY SUTTON: Yes, there is a document† we did this at the last camp. We had a whole session around it. We just decided to do it separately this year. It is linked from the home page of accessibilitycampseattle.org. You can go to the Google doc.
5 Rookies Accessibility Engineering Mistakes?
I’m relatively new to accessibility, so it was really cool to see† one, just to kind of be reminded of how expansive this can be and there’s no onesizefitsall solution. It was cool to see that people were trying to bounce ideas off of each other and how collaborative this group is and we all make a lot of mistakes, just like every other facet of tech, which is great.
MARCY SUTTON: Saw more hands. Anyone else?
I was really interested in the fact that, I guess, ARIA guidelines, it’s better than no ARIA.
MARCY SUTTON: The rules of ARIA is definitely worth checking out. The first rule is don’t use it.
Do you have anything you want to add?
I was just going to say, I found it super validating that other people were making the same mistakes that I made and none of us are alone in our work to make the web accessible.
DEVON PERSING: Do you want a shirt or some socks?
MARCY SUTTON: Okay, popular UX and UI Patterns and Accessibility.
This was one of my favorite talks of the day and I think a direction that we should really be moving in, in the industry, which is to start talking about the complex patterns and the ones we don’t have specifications for and the design patterns that we don’t have good answers for. So, yeah. Give this again, anywhere you can.
MARCY SUTTON: We have spillage.
Did I see another hand for comments on that one?
Okay. Designing for the Extremes? Joanna?
[Away from mic].
I don’t do it nearly the justice that you would. I liked the point that if you design for both extremes, you’ll catch everything in the middle. Joanna turned the typical paradigm inside out in a way that I’m dying to replicate now.
DEVON PERSING: Shirt or socks?
Is the extra large shirt still up there?
MARCY SUTTON: It is. I was going to ask what the extremes are, for those of us that weren’t in the room?
Concept of most designers focus on 80% of the market. But, if you think about it, people who live outside the average user, like, your goal customer is your customer with disabilities and, like, maybe your power users are on the other end of the spectrum. If you can design a system that has every bell and whistle and every nob that every customer would want to turn and make it simple enough that it can be used with a screen reader, everybody can use it.
MARCY SUTTON: Yes. What an awesome way to think about it.
Accessible Maps Discussion? I saw a lot of cool things being discussed in that room.
So, we covered a lot of ground. But, the† one thing that I took away is that there’s a lot of different uses for maps and we generalize them to, where am? How do I get there? What is around me? What’s a oneway route? And there is a set of places† and I need to describe a set. And then, the considerations that we went into with those use cases is, different levels of vision, distractibility and I had one that I can’t think of right now.
The level of distractibility.
MARCY SUTTON: That could go in the resources doc. That’s where we can connect to notes and all kinds of things you learned today.
User Testing With People With Disabilities.
So, this session originally said, interviewing and supporting people with disabilities in the interview process. The proposer meant user testing with people with disabilities so we kind of addressed both of them. I feel like we mostly talked about the process. A couple of points that came up, that were very important, are kind of bringing our hiring practices to† to the people. So, people with disabilities or especially vision impairments, it’s difficult for them to use a lot of social media and so advertising for your jobs, on social media, isn’t very equitable for people with vision impairment. So, bringing jobs to those people.
Identifying your personal biases, instead of acting on culture fit, acting on a culture add and looking for kind of what thought you don’t have in your† in your current team.
Yeah. I think that’s [Away from mic].
MARCY SUTTON: Super cool.
Would you look a swag?
I’ll have a sock.
DEVON PERSING: A sock, yes!
MARCY SUTTON: Accessible Case Studies.
DEVON PERSING: They’re very soft.
MARCY SUTTON: I heard lots of laughter, from the room next door, so it sounded good.
DEVON PERSING: It doesn’t help that the back wall is very vaguely skincolored.
This was very cool. It was very ad hoc. We had great people who happened to have stories they could tell immediately. We heard about a case study with alternative navigation for a website that didn’t necessarily rely on assistive tech, like screen readers. It was a proposal to simplify. It was super, super interesting. We heard from Starbucks, which was really cool, as well. Talking about color contrast and what to do if your brand color, by default, is not going to be easy to fit into the color contrast of WCAG. I think that’s a lot of where the laughter came from because there were a lot of challenges in that. Lots of really cool, I guess, visual aids and things to help people make those choices better, going forward, as well, was really cool to learn from.
Thank you to everyone who provided case studies. They were really awesome.
MARCY SUTTON: More Inclusive Web Accessibility.
So, this talk was mostly about defending people that might not want to use assistive technology interesting. And there were six reasons why people might not want to use assistive technology which are things like cost and the time it takes to learn assistive technology and all of those reasons. So, that was really† a really cool perspective.
The person that gave the talk had an alternative, which was, just making sites kind of by default, more accessibility. So having narration kind of start automatically, after a sixsecond delay. Stuff like that. It was really kind of a new take on inclusion.
MARCY SUTTON: Making a Business Case for Accessibility.
So, this was really interesting. I think that if we were to boil it down, the thing that was most educational, for me, was we’re all kind of aware that if you tell your boss that we’re going to get sued, then they’ll listen to you. But it really limits the type of conversation you’re going to have about what you might make and what “done” is really going to mean. This presentation had a lot of really good ways to insert positive, aspirational goals in front of the doom and gloom, we’re going to get sued point, on the slide. And a lot of those were really encouraging and, I guess, to share one, just the way of making things more accessible can benefit everybody, all users, not just people who might need those. Just kind of leading your pitch with the good you can do.
It was a race because you said exactly what I was going to say.
Mainly because I bring this up at work to create a case for accessibility for clients we serve, that’s the first thing that comes out of people’s mouths, oh, we can tell them they’ll get sued.
MARCY SUTTON: Do either of you want swag? There’s some killer socks up here. We have two large shirts and a small shirt and lots of socks and some of these fantastic “read more” buttons. If you wear multiple of them, they’re really funny. It confuses librarians.
Accessible Event Registration Pages?
So, we talked about some of the ways that screen readers read or don’t read registration forms. Some of the technical kind of things that go into that and also, how to deal with vendors and ways we can talk with vendors who provide those services to us, to make them accessible, and then it’s not our problem as much.
Although, of course, it’s still our problem.
MARCY SUTTON: Yeah. To add on to that† because this is something I’m having to do a lot† is to push vendors to up their game. I want to encourage them to do and make that business case and not leading with “you’re going to get sued.”
Yeah, that one was really cool.
So, Microsoft Accessibility Insights Demo?
I really liked the visual interface we’re seeing. It’s stuff I’ve been working on with people, who are just starting to understand, from a designers perspective, what it looks like when you’re doing annotations and designs and having that reflects in an actual web space. It’s super cool. That’s all I got. It sucks.
The other highlight of that session was running the accessible tool on the results of the accessible tool.
MARCY SUTTON: How did it go?
It was great.
DEVON PERSING: It opens in a separate page, in a separate window. That’s pretty cool. Would you like some socks?
MARCY SUTTON: Accessible Camp Seattle meetup organizers info session.
We talked about different ways we can activate the meetup and what people are actually interested in, whether there are different kinds of events and whether there’s more for social events or go out for beer events or speakers or venues and then wrapped up with, hey, let’s talk about this on the Slack channel.
MARCY SUTTON: Today’s magical, we have one more session to talk about. But part of the goal of the organizers info meeting was to figure out how to keep this energy going because we have such a great community here. So if you weren’t able to attend that, the next steps we have for where rubber meets the road, there’s a web accessibility Slack. I’m going to add it to the resources doc, so you can get in by, you know, contacting me and I can invite you. And in there is an Accessible Seattle channel and that is where we can collaborate on, hey, I’d like to host something on this date.
That’s the goal, to keep the meetup going and this camp going and we need your help to make this possible. So, thank you for coming to that session and let’s talk about one more. Did Accessible Hacking Track happen? No. So, we have one more.
Testing Tools and Process for Accessible, in the back? Backish.
Thank you. So, a holistic view of what you can do to make a website accessible. We went from the linking tools or the way to plugins, we talked about Axe a little bit and Insights and screen readers and JAWS, those kinds of tools and lastly, he mentioned about usability testing.
Yeah, there were a lot of great resources for all parts of the testing up until integration testing. I’m definitely going to look into Axe CLI for doing Axe testing into my integration, to the build pipeline and look up Scott O’Hara. And this was something I definitely am going to watch out for is giving people minimal training on a screen reader and telling them to fix screen reader bugs, is just a way to make worse bugs.
MARCY SUTTON: Yeah. User testing, with people with disabilities. Super important.
Well, that’s pretty much† that was the day. I’m so excited† oh, wait! More comments. We have time for more comments. Hey, Devon, we’ve got one more.
DEVON PERSING: I got to orange for socks.
With regard to the test† the tooling talk, I thought it was interesting, I don’t remember the source of this, it catches between 30% and 60% of the issue. It underscores how important it is to actually verify this. And, something else, that we can† maybe never guarantee 100% accessibility, but we can talk about the steps we’re taking to make things better.
MARCY SUTTON: Love it. Yeah, you can make it part of your process, to do that automated stuff for the lowhanging fruit. The most common errors are the easy ones, like color contrast is number one. A lot of the things that can be automated are the common ones. So at least there’s that. There is the necessity for manual testing and user testing. By getting that lowhanging fruit out of the way, you can save that energy for things that need human experience to validate. Is this alt text good? It’s not making a human test all the things that a checker could find. It’s like, save those resources, like, their time and energy for more complex things.
So, that’s our day. We are planning to followup with a survey afterwards, to figure out† oh, that’s me.
Figure out what went well, you know, what we would hope for in the future. For the Accessible Seattle Meetup because we’re all one, big, happy family and we’d like to keep this going. That’s all we got.
Mainly, just a big thank you to everyone for investing with us and, like, spending your time discussing things. Thanks to all the people who lead sessions.
DEVON PERSING: Please take sandwiches home.
MARCY SUTTON: Oh, yes!
DEVON PERSING: Please take sandwiches home. Or just give them away. I don’t care.
MARCY SUTTON: It would definitely help us to distribute the food. We have a lot of things to pack up, so that is something we could use your help with is make sure the food goes home.
Any other comments or questions? Like, we don’t have to lever.
There are a lot of homeless people in this neighborhood [Away from mic] sandwiches.
MARCY SUTTON: That sounds fantastic.
Thank you for organizing.
[Applause and cheers].
MARCY SUTTON: I’m kind of sad. Thank you, everyone, for coming. Go forth and conquer the world.