In the modern software development process Designers are "The Voice of the Customer", we represent their interests not only throughout the design process but throughout the end to end delivery of the product.
As such it often falls to us to bear the responsibility of creating and maintaining accessibility.
Let's talk about what I consider the 5 Pillars of Accessibility:
Behavior
It does what the user expects it to do.
Journey
The Happy Path is well-marked.
Style
Your color contrast is on-point, and your <H1> is clear.
Technology
It's screen readable and properly tagged.
Legal
Your legal team gave you the nod.
Pillar #1: Behavior
Humans are pattern matching machines. Our brains have evolved to look for patterns. Have you ever wondered why Spotify can find music for you, week after week, that you love?
It's because they are finding patterns your brain likes.
We do this everywhere, door handles being push vs pull, turning a knob clockwise to open. When you go against the 'expected behavior' of anything your user is experiencing it immediately breaks the experience. Designing for behavioral accessibility comes down to anticipating what response the user expects for an action.
If they press Enter, they expect it to send a form, if they hit tab, they expect it to move to the next item in the form. This is especially important if the user is using accessibility tools like screen readers, but we'll come back to that later on.
The example below is lifted from a real web page I found while researching this case study and is live as of 2020.
By having Tab go over one column and down to 'Email' instead of across to 'First Name' you've now created confusion for the user by not only not doing the expected Behavior, but by also doing something unexpected.
Did you notice the other glaring Behavioral flaw with this page?
Last Name first is common in legal documents, but is incredibly uncommon in Job Applications. In fact this is the only time I have personally ever seen Last Name First in a job application.
Do what they expect.
Research what your common pattern is, and do it.
Consider what the user will be expecting and try to fulfill that need.
If you are ever designing a form and aren't sure if you've organized your screen in the best way, this is the perfect time to get user feedback. Ask your user to try your form out and look for any spots where their behavior didn't line up with your expectation.
Pillar #2: Journey
Let's look at a webpage I designed for Ford.
When re-designing the Lincoln Credit pages for Ford we set out to have a Primary CTA, and a Secondary CTA that were visually distinct and offered two options within the same experience.
The CTA's would often be used to met the #1 and #2 goals of the customer, or to server a Primary and Secondary Persona.
We often set out to identify the #1 thing a user wanted to do on any specific screen, and highlight that as the primary.
But what do you do if you want to give customers more choices?
Define the Journeys.
Make Happy Paths
If you ever aren't sure what Journey to take a user on, decide what the #1 thing they want to do on a screen is, and create a happy path around it. Plant some trees, build a fence, and use CTA's as your sign-posts.
Well defined Journeys reduce confusion and assure that your users know what they should be doing on a page.
Pillar #3: Style
When considering accessibility your Style is largely broken down into: Color & Text.
Let's start with color!
Intelligent application of color isn't about what colors you choose to use, but how you apply them.
Let's start with contrast, below are the 3 primary brand colors for Lincoln Automotive.
Let's try making buttons with them using white text.
Also beware using your brand colors for messaging. If you have an orange (usually a danger color) as part of your brand beware re-using similar colors.
The other side of the style coin is Fonts - you want your users to understand what is important on a page and you direct their attention through consistent use of fonts, colors, and sizes.
Pick combinations of fonts and sizes and use them consistently. Define what your <h1> <h2> and <p> tags are and use them consistently. This will allow you to communicate clearly with your users as they will come to expect that text that looks a specific way conveys a specific message.
Header
Sub-Header
Lorem Ipsum Dolor Sit Body Font Amet Consecutor.
Another thing to keep in mind is that behaviorally - users expect bigger text to be more important. Keep in mind that the first thing a user will see is often the largest.
But no matter what - be consistent
If you decide Blue is your success color, use it anywhere in the application that something succeeds. Anytime someone embarks on the primary path in a Journey, use a Primary CTA. If you have important decision trees, make sure that the buttons for YES and NO are always consistent.
Once you have established a clear <H1> never change it. It's the same throughout the entire experience, if you decide on a specific element <H1> isn't working, move to <H2> before you change the style of that element.
Pillar #4: Technology
Screen readers at their core allow users to 'hear' your webpage, and as designers we primarily think in visuals.
It's important if you know a core part of your audience may be disabled to review the experience that a customer has when using a screen reader.
Take the Journey your users are experiencing using screen readers yourself! Make sure that the experience you're building works via screen readers first-hand. Conduct user interviews with users who rely on screen readers and look for places you can improve.
Consider the requirements that are being sent for development - add functional requirements into your stories that make sure you have <alt> tags on images and your semantic structure works in a screen reader. Work to make testing with screen readers part of your normal QA process.
A lot of this really lies on the shoulders of the developers, but we as Designers are supposed to be the voice of the user, make sure your developers are keeping screen readers in mind when developing the front end and help your team define accessibility requirements in acceptance criteria.
Pillar #5: Legal
Ask for your lawyer.
This may sound like a weird one, but the legal team at a company exists to make sure your bases are covered.
When I was designing at Ford we would regularly send screens and copy to Legal for approval because our skill-set is "Design Great Software" not "Design Software That Doesn't Get Us Sued".
The industry you are in also makes a large impact on this, when I'm designing for financial services or another heavily regulated industry how we present things to the end-user can be legally binding, or dictate legal requirements.
Don't be afraid to pump the brakes and ask for legal review.
