April 4 @ 2:00pm
An Event Apart Seattle 2018
He’s been bringing us design and accessibility information for years. BoxofChocolates.ca is where Eric first discovered him.
Luke Skywalker was a brash, arrogant young man who thought he was ready to become a Jedi, and he meets with Yoda not knowing that he was Yoda. And he’s saying ‘Come on! You need to take me to Yoda now!’ And Yoda says, ‘All in due time, patience, young man.’
Derek showed a scene from Star Wars where Luke and Yoda are arguing about whether Luke is ready to train.
He saw sketches in a Star Wars exhibit showing the sketches that made up the original storyboard from that scene. That is essentially the same as our wireframes.
What he’d like us to do is think about the things in our process and think of wireframes not as static representations, but more like storyboards – things that have detail in them that will help the team create the final product.
This talk is really about creating inclusive user experiences.
Derek is working for somebody else for the first time in 20 years. Last month Level Access (his company) got acquired.
We review wireframes because they allow us to predict and prevent accessibility issues. We can tell if there will be challenges in the interface just because of what we see in the wireframe.
But what are we looking at? What’s the difference between accessibility and inclusive design?
Accessibility is an outcome.
Inclusive design is a process.
You can think of inclusive design in the noun form. (Inclusive is the adjective, design is the noun). But he wants to think about it as a verb as an adverb.
Inclusive UX design is about being really intentional. Intentionally crafting and designing each interaction and incorporating inclusion as a core value. We can accidentally design something that was accessible, too.
When we do this by accident, it’s ok, it’s a good outcome, but ideally, we’d have it as part of our design and build process.
Techniques for Teams:
There are process and implementation pieces of each of these techniques.
- Communication
Look at your wireframes and storyboards as a communication tool.
This wireframe gives us a certain amount of direction but doesn’t give us all of the information we need to build the thing. It starts becoming useful when we add annotations like order notes and focus path notes, which makes this much more akin to a storyboard than a wireframe.
This level of direction helps people NOT make assumptions or guess when building it. The wireframe without annotations, if that gets passed to a developer, might get developed a certain way. It might also get passed to someone to test it, but without those notes, they don’t know what the intention was so they can’t adequately test it.
The core value of a wireframe is in the conversation, not in the boxes. We need to use wireframes as conversation starters!
People will disagree about the order, and that’s ok! There are a lot of different ways to code things. Using the wireframe as a storyboard and conversation starter allows us to get those disagreements out of the way upfront.
- Reverse engineering
When analyzing a site to see what could be improved, when they see something that wasn’t done well, it helps them to reverse engineer it.
Example: A left sidebar with a triple-level fly-out menu. They work backwards and build the wireframe after the fact to see that problem would have been caught at that level, and if that had been done it would have saved that particular issue from ever happening.
On mobile, we can shrink content, but with controls on mobile, those actually need to be bigger. So for example, if you have a carousel on the desktop that has arrows on the right and left and dots at the bottom,
On mobile, if you do only 1 thing for accessibility, he wants it to be these 3 things (ha):
- Prioritize your content
- Make your controls larger
- Give the controls breathing room
The big question in the wireframe/storyboard stage: HOW COULD WE PLAN FOR THIS EARLIER? This reduces the amount of wasted work.
- Interaction tables
This is the kind of thing we should do for all of the things we are building.
An example with accessibility and a carousel: When someone using a screen reader interacted with a carousel slide, the screen reader would
This is essentially a storyboard in words. It maps out all the events/interactions for an element and what we expect/want to happen.
There is value in the reference and value in creating it together. Designers and developers LIKE getting together and talking about these things! So, yes, it’s valuable as a reference but also because it brings you together and gets you talking about things.
Techniques for Designers:
- Color Schemes
Color schemes and brand colors are very helpful to have, but we need more details than just
We need to define good combinations AND bad combinations, as well as large font-only color guidelines.
Have a color contrast ratio of 4.5:1 or greater
If you’re using large text it’s 3:1
That’s a measure of 2 things: The color difference and the luminosity between the 2 colors.
Generally speaking, think 24pt or greater for a large font.
- Design Intention
Make it very clear what our design intent is!
Banks found that people made a lot of mistakes when making payments or making transfers, so they built in the screen that said ‘Wait are you sure you actually want to do this?’ and then the user had to confirm the action.
So to improve this they wanted to change that notice to be less jarring and be a ‘Slide to confirm’ action. It’s hard to ‘slide to confirm’ accidentally. It’s easy to tap on something accidentally, but harder to slide.
They also wanted to make it accessible. So they asked how they could do that.
For screen reader users, they’re going to hear the words ‘slide to confirm’ but it’s just a button that looks like a slide bar and responds to the slide action, so it could be triggered with a voice action too.
You can actually double tap on that slide bar and it will activate the button.
For somebody that uses a switch, this slide action will work as well.
They also decided they needed to allow for some vertical leeway
But then Derek asked ‘but why are we even doing this?’ and their answer was ‘we don’t want people to do this by accident.’ So really what needed to happen is to require an action that isn’t common or used everywhere else so it’s sure that it’s intentional. For example, have someone draw a square to confirm.
Lesson: They needed to know that design intent so they could figure out HOW to make it accessible, not JUST to make it accessible.
- Interface Transformation
Example: A carousel vs a list or grid
They were working with a website that sold cars, and they had a carousel that required horizontal scrolling to see more cars. On mobile, you could only see 2.5 cars at a time. So it came back from testing that it was very difficult to make the horizontal gesture, so instead, it was decided to just put the cars in a vertical list on mobile.
People are going to want to interact with things differently and we need to account for that.
So we should build in transformable interfaces. Ideally, we could provide someone the option to switch from carousel to list view.
We are already starting to do this with animations, where we’re building in the option to turn those animations off.
Techniques for Developers:
- CSS class name review
Look for these class names in your code:
class = “current” or “active” – you’re building meaning into your code. New in the aria (accessible rich internet applications) is the ability to set aria-current on different things:
aria-current = page | date | time | step | location
class = “expanded” / class = “collapsed”
Use this class but also use aria-expanded = “true” or “false” on it.
class = “error”
Yes keep using this class but also use:
aria-errormessage = “ID”
Look for the meaning in your CSS and move it to another layer like HTML or ARIA.
- High contrast tweaks
Example: Drop shadows on older sites were created using actual background images. When switching into a high contrast theme, the interface is completely flattened.
All kinds of things disappear in high contrast themes like form fields with no borders.
You can add a 1px solid transparent border around things that need to stand out from the background and those appear when in a high contrast theme.
Look for meaning in your visual design and represent that in HTML or ARIA.
- Working with gestures
They built a data-table that was sortable by swipe (swipe down made is ascending, swipe up sorted it by descending). Gestures are already in use by people that use assisted technologies on a mobile device. So this didn’t work because for people using those assisted technologies, swiping up and down actually moves you to the next element on the page. So for them, that gesture didn’t sort the table, so they had to build in another mechanism where they could tap on the table header and it would toggle sort by ascending or descending.
Yes, we can use the gesture, but we need to talk into account that it may be really difficult for someone or they may not be able to do it at all.
Consider simple, complementary methods (like tap) to use with gestures. Let’s provide a really simple alternative to our gestures.
- Black holes
Not black holes in space, but keyword black holes…
Having “Page 1 of 2” listed somewhere there are multiple pages is a really good idea – it sets the expectations for interacting with that carousel and helps someone decide if they even want to interact with it.
These carousels could hold 300 items and if you don’t know that going through it. If you don’t have any context, you can’t decide if you want to go down that black hole or not.
But we need to do more than that because 2 pages of 30 is very different than 2 pages of 6. So let’s tell people how many items are on the list! We can
Read: Liminal Thinking by Dave Grey
Lesson: Help people answer the question ‘What happens if I go down this path?’
Wheelchair ramp example in Mexico: THIS IS NOT GOOD.
Maybe they thought ‘ok we need to make a ramp for wheelchairs but it doesn’t meet any accessibility requirements, plus they didn’t think about how someone was going to get OUT of the store. It’s super dangerous! They’re gonna go right into the street!
Let’s not just think about how someone can use our stuff, but also how they can STOP using our stuff.
- The implementation itself is important.
- The process – if nothing else, embrace this process.
Thx, very helpful!