Why aren’t more apps and sites Accessible?
What is accessibility or a11y as it is often abbreviated? There’s a lot to it, but in a nutshell, accessibility is about making a site or app usable to the greatest number of people possible. Ideally, it’s a delightful experience too. It acknowledges that people may have permanent or temporary disabilities which make it difficult to use them. Accessibility best practices don’t just cover visual challenges but also hearing impairments, motor coordination issues, and cognitive disorders, to name just a few.
We’re all a little disabled sometimes
In fact, many of us without permanent disabilities may find ourselves technically disabled on a regular basis.
Here are a few examples:
- In a loud environment, turning on captions can help.
- Lost your reading glasses? Make the text bigger.
- Driving in the car and need to respond to a quick notification?
- Larger buttons, text and few choices help you when driving from a motor coordination, visual and cognitive standpoint.
Government work (in the U.S.) often references section 508 but a more universal and up to date standard is WCAG 2.1 (soon to be 2.2). There are three levels to WCAG. A, AA and AAA with AAA being the highest. Most projects would only usually need to conform to AA but government work might require AAA.
There’s often internal friction making a11y happen
In my experience, although making it mandatory to include alternative text for images is great, it’s usually the “fig leaf” concession for accessibility. Truly accessible interactivity and forms can be very challenging from a technical standpoint. However, getting internal buy-in from both business stakeholders and other designers to provide good color contrast, large enough text and even form labels is many times the real challenge. This is because it’s often in conflict with existing brand guidelines that use inaccessible colors and fonts. It also sometimes goes against the modern, minimalist tiny text, low contrast, “clean look”. The good news is that whitespace is key to both and in some cases text styling expectations are changing.
Throw in the need for additional budget to re-design for better accessibility, perhaps higher development cost plus effort and you have a recipe for doing nothing (unless spurred by legal action).
Let’s acknowledge the reality — there’s some friction
Branding often wins out
Organizations do invest a lot of time, effort and money into their branding and don’t want to change it and get out of sync with their other projects or assets without good reason (from their perspective).
Accessibility work may be perceived as a hinderance
Projects and initiatives also generally have tight budgets and timelines. Adding accessibility design and features into the project is usually viewed as driving the cost up for little perceived gain aside from legal liability protection.
Buy-in and motivation aren’t sometimes there
Designers and developers are busy and don’t always have the motivation or the training to engineer their products according to best practices unless working on a regulated government site or app. They might take a stab at improving things, but the motivation from above and the resources to actually design and implement those best practices are often lacking, inconsistent, or, more to the point, not viewed as a good match for the specific product requirements.
General resistance may exist
For some designers, accessible projects that deviate from the “standard” might not look as good in their portfolio or call into question their abilities by higher ups that only evaluate them according to the visual “sizzle” of their work. More charitably, one could argue that they view it as stifling creative options to push the envelope and differentiate projects from the competition. Their organizations may feel similarly. These can be valid concerns.
I’m calling out designers and not developers as much (although they may push back from an implementation standpoint as well), because designers are where the nitty gritty concrete examples begin to be shaped. With that said, the will to be accessible does come from the management even if a case can be made from the bottom.
Harmonizing the friction
Many browsers have accessibility work arounds and the state of things is getting better. Device operating systems like iOS and Mac OS in particular make a real effort to provide features to increase accessibility and applications like JAWS + Chrome have a pretty good track record. However, there’s a limit to what can be done on the browser or device side if the basic content is not that accessible to begin with. Designs and interactions may “break” in unexpected ways when these workarounds or features are applied making the experience unusable and frustrating.
Beyond alt text
While I fully believe that certain accessibility features are a baseline requirement, like alt text (where alternate text is given for images) and video captions, we need to acknowledge the friction that exists for business, designer and developer project stakeholders in terms of actually implementing more fully featured.
Like it or not, the friction over accessibility exists whether it’s directly stated or simply silently ignored in favor of perceived speed, cost reduction and “brand” integrity.
These are big complex problems. If they were easy to solve, all sites and apps would be fully accessible. They’re not. With that in mind, I’ve been thinking about some possible tactical and strategic solutions to at least make more progress to harmonize that friction with an eye to improving this poor state of affairs. If anyone has other suggestions, I’d love to hear about them!
Possible approaches to reduce that friction
Enhanced Accessibility mode
One of these solutions might be to create an Enhanced Accessibility (EA) mode in a similar manner to Dark Mode that is being enabled everywhere.
This is different from the toolbars you sometimes see on accessible sites which let you set text sizes, color contrast etc. It would be a one click option that could appear in an initial message or alert and/or is always present in the navigation.
Here’s a link to the super basic Fiddle I myself forked from an example of a basic dark mode theme switcher. Feel free to fork and play with it.
This allows for an “alternate design” to be applied, which wouldn’t necessarily conform to the default branding but would be less subject to breaking and would somewhat match the default overall look and feel.
It’s a larger version of turning on closed captions except it’s doing things in bulk with certain applied defaults. In a best case scenario, users would still be provided control over what is displayed, but an EA mode might be an easier sell than needing to integrate and implement a toolbar and all the associated options. Essentially, from a practical standpoint, it’s a theme switcher.
The point of friction that it reduces is that there is now less of a need to advocate for a wholesale change of design.
This isn’t to say we don’t keep trying to make the “default” design accessible but it can make it easier to move the needle towards getting something in front of users that is better.
For example, where the case can’t be made for some WCAG conformance from a branding standpoint, applying EA might result in:
- Increased text contrast
- Increased title and paragraph text
- Application of certain more standard device fonts if a more decorative font is being used
- Standard links, focus and active state links would be more prominent
- Forms would have labels applied
- Icons might show labelled descriptions
- Animations would be muted
- Text spacing would increase
- Button hit areas would be larger as well for as any other interactive elements.
- Colors might be transformed to reduce reliance on red and green or a black and white version used
- Captions turned on by default for video
The end results may not look like the “un-enhanced” version or be totally accessible, but at least they won’t require users to constantly fiddle with accessibility settings and the site/app can maintain its branding while offering a user chosen alternative with less overhead.
It may also give the organization a better idea of who is opting into the EA version and how many are doing so. If usage is large enough this may encourage efforts to integrate what is in the EA to be integrated into the “regular” version.
Of course, this still takes work on the design and development side. Which takes us to the other point of friction. Time and cost.
Execution needs to be cost effective and convenient — changing the defaults
There’s a trite saying, “A lazy developer is a good developer.” Kindly interpreted, it means that the dev wants to find the most efficient method possible so they’re not doing repetitive, extra work. This can also apply to designers in the sense that they shouldn’t be reinventing the wheel (e.g. common design patterns) if they don’t have to.
Because of the prevalence of component based development, design is starting to be influenced by that approach as well. Design Systems are taking over and the most popular design tools Sketch, Figma, and Adobe XD all support a version of component based design. Pre-made kits are everywhere and Material Design associated, Bootstrap , Tailwind based components and iOS kits have had a huge impact on current digital design.
On the dev side, 3rd party frameworks and libraries are viewed as critical pieces to efficiently and rapidly create and iterate.
As a possible solution, I’d like to propose that the design community adopt kits/libraries/systems that are Accessible First (to paraphrase Mobile First).
They should include annotated accessibility advice and best practices for common design patterns. The process should guide them towards creating content and task flows with solid Accessibility and only then diverging into something with the more typical “branded” treatment. Something along the lines of Figma’s new variants would be great but applied to entire art boards or pages might be helpful.
In much the same way we mock up mobile, tablet and desktop formats, we’d also display what the EA format looks like. This encourages designers who’d want or need to create sites or apps that are less than accessible in their regular mode to easily demo what it would look like in EA mode.
In a similar manner, development components could have the same treatment applied. Ideally the design library dovetails with the developer framework enabling a more streamlined implementation.
Using this approach, organizations might reduce the overall cost and inconvenience of incorporated real accessibility into their workflow. In addition, the more “industry standard” kits and packages integrate a11y practices, the more likely we’ll start seeing the state of things improve.
Let’s stop the insanity
To quote another overly used bromide,
“The definition of insanity is doing the same thing over and over again and expecting a different result.”
Let’s stop doing that.
Although I’m not happy suggesting a less than ideal approach to accessibility like using an Enhanced Accessibility mode, I feel that the “elephants in the room” are often ignored and their concerns aren’t really addressed except to say, “Do better!”. Then everyone nods their heads and keeps doing what they’re doing or implements some token gesture to say they tried. As a UX Designer, I try to address pain points wherever possible and at least seek to iterate on/mitigate them if they can’t be completely solved.
We can do better. But we can’t do it if we don’t address the underlying friction often standing in the way.
Have some other ideas? Want to help? Reach out or make your voice heard. ;)