Accessibility is for Everyone

Accessibility Symbol

People often leave Accessibility in design and coding to people with less important problems and more time on their hands. I think this comes from misunderstanding what it means to make an app or website accessible in the first place. And I find it kind of ironic that the term Accessibility itself is inaccessible because it’s jargon.

Think of your app. You made it, no one’s used it before. If people struggle to use your app, it’s more likely that you’re inconsiderate than that your user is incompetent. Developers get paid to make apps normal people (let’s call them Muggles) can actually use.

When I came into software dev training at the Flatiron School, I imagined the best code was brief and cryptic, like haiku for computers. But we don’t only write code for computers- we write it for other coders. Please enjoy my code haiku below though:

function x(y,z){
b = y.map((a) => (
z.//I give up)} 

Writing for other coders creates accountability for otherwise rushed decisions, resulting in a better end product. You know, like something that makes sense after the bathroom break too…

But what about writing and designing apps for other people, like just generally? Like, what happens when we start to consider people with common disabilities we don’t personally have? How do we even? Can we even?


Designing for situational disabilities

Starting with broad strokes is a good way to begin designing for people who are not me. As in, people who would pay a developer for work. We can start with people on their phones, as opposed to my fancy MacBook Pro:

Phone is too big, can’t reach the button

Clickable elements need to be within the average thumb’s distance.

Diagram of touchable points on an iPhone

Spotty reception or slow connection

Avoid bloating page content. For instance, don’t use auto-playing video content on mobile views.


We don’t all see the same

Vision is the first thing I think of when I hear about Accessibility.

Some people don’t see webpages

They use screen readers instead. Screen readers speak web pages aloud. They navigate pages based on HTML tags and ARIA attributes, which are some of the easiest code to neglect. Describing the sections of a page for screen readers is like describing your functions. It leaves less room for sloppy or arbitrary decisions.

Some people navigate with the Tab key

A very common offense here is using CSS to disable outlines on focused elements. Without the outline, people who navigate by keyboard won’t know where they are.

As a side note, paying attention to usability tends to produce better style overall


We’re all on the spectrum

That’s what makes it a spectrum. Reading about Accessibility for people on the outer edges of the autism spectrum, feels like a primer on UX. I got the sense that the main difference between people on the far end of the spectrum and myself is their sensitivity to things I pretend don’t irritate me. For instance the white paper above mentions these items in the context of corporate events, but they apply to designing user experiences in general:

Limit loud/unpredictable noise, motion, and other stimuli

Blinking or flashing text fields in horrible colors are the classic no-no from 90’s-era websites. Then MySpace tuned us in to the idea that empty (“white”) space is more than a suggestion.

Animations on modern websites are usually best to use in response to user actions, rather than trying to grab attention.

Don’t create unpredictable events

Pop-ups are the classic case of an unwelcome, unpredictable event happening during your user experience. After popup blockers became effective, designers started using in-window popups instead of new-window popups. They came up with fancy names to describe them too, so that muggles wouldn’t know how to complain about them en masse:

  • “Modal” windows set to pop up without user action, obscuring active content. These often pack a double-whammy for people who browse the web with keyboards and screen readers (see this example) because they don’t include accessible ways of closing the popup- even for people with perfect vision.
  • “Interstitial” popups- a fancy word for the kind of ad that takes over your entire screen for 5…4…3…2…1… before you can access content. These are a huge turnoff to users, and trigger an SEO penalty on mobile.

These often come with a shaming element to complete the arm-twist:

Intrusive popup "modal"
Please just don’t even

Use simple language

Please spare your reader’s inexplicably diminishing cognitive faculties by saving the long words for your next angry email.

Only use jargon and complex language where necessary. Big words crowd out the point, and cause users to skim or go elsewhere.


Last thing: divide content on the 3’s if possible. I’ll tend to write helper function if I’m writing the same code more than twice. In design you can use visual cues like the HR element above, or hide the additional content behind tabs or in (jargon alert) an accordion pattern.

Wow such clever!

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

Mark Bello

Mark Bello