The internet has come a long, long way since the plain HTML pages of the 90's but when it comes to accessibility, our problems remain the same.
So, you want creative AND accessible content.
And I'd like a million dollars! Some things are easier said than done. Fortunately, you're not the first to dream this dream.
We as developers have been gifted some pretty powerful tools when it comes to creating custom components that utilize accessible practices. But it seems more and more often we find ourselves handicapped (the irony) by the lack of available options for designs that break the mold or challenge existing patterns. In the time since the advent of web accessibility, what developers are required to do to make a web page accessible has evolved far from simply using semantic HTML.
WCAG, perpetually behind the curve.
The release of WCAG 1.0 in May 1999 was the first major step in creating a universal framework for web accessibility. Developed by the World Wide Web Consortium (W3C) under its Web Accessibility Initiative (WAI), WCAG aimed to ensure web content could be accessed and used by individuals with disabilities.
At the time, web pages largely delivered text or images. The amount and complexity of interactive content we see today was something developers could only dare to dream. I like to think that telling W3C what the internet would become would be like trying to explain the concept of 3D printed beef to a farmer in the 1700s.
Even still, WCAG 1.0 received criticism for being overly technical and not addressing dynamic content and newer technologies. This seems to be the trend even continuing into WCAG 2.x and WCAG 3.0 drafts.
Innovating with ARIA
While WCAG helps set the guidelines for what developers and designers should be doing to create accessible web pages, ARIA actually helps us "walk the walk" by giving developers the tools to communicate our web page to visually impaired users. And while this is hugely helpful in creating components that don't follow semantic HTML patterns, we can still only work with the tools we are given.
There have been many times in my career where I've had to stretch a component to fit an existing aria role that maybe didn't map to the ideal behavior for design. Sometimes you start with a role that fits until design adds a wonderful new feature that breaks the model and sends the house of cards tumbling down.
Fortunately, as part of WAI ARIA gets pretty frequent updates. I do appreciate a lot of the new attributes and roles that are being made in attempt to keep up with the evolution of web pages. But ARIA itself means nothing without support from the browsers and screen readers. If your application is supported by a version of browser or screen reader that doesn't yet communicate with the latest and greatest ARIA features, you're SOL.
I personally have been patiently waiting for the aria-description property to exist draft status all year. There's nothing like receiving a shiny new hammer and realize support for nails doesn't drop for another 6 months.
What to do when that thing you want to be accessible just isn't?
I'm a certified dream-crusher when it comes to telling designers that their component just won't work with the given criteria. I always recommend UX/UI designers familiarize themselves with WCAG patterns and ARIA roles so they know the difference between shooting for the moon and colonizing Mars.
Accessibility requirements can be pretty strict, and when the consequence is "potential lawsuit" you know companies are going to be very thorough in their compliance. The safest answer to "My component isn't accessible!" is "Back to the drawing board!" But part of me does wonder if there's an upper limit what kind of content can even be accessible.
Back when I worked for a bank we had a credit score gauge that displayed a user's score once clicked. We had some lovely SVG animations that filled the gauge according to the user's score. It was a legal requirement that the score couldn't be displayed until the user clicked it. This posed an interesting problem as it made a component that perhaps wasn't traditionally interactive into something that required user interaction to display. To circumvent a lot of the accessibility concerns with this, we elected to give treat the gauge as a picture to screen readers and added a button for the interactive portion of the component. We dynamically populated the alt text of the "image" with the score information and this worked well enough. Even if it's not entirely semantically correct to identify the gauge as an image, to a non-sighted user for all intents and purposes it was.
However, some features just don't translate to accessible design. Things like augmented reality and hot spot selection of images are just not features users with visual impairment will benefit from or enjoy. You won't find a keyboard responsive way to allow a user to manually sign their name on a web form. Does this mean you shouldn't implement features like these? Absolutely not! But designers and developers must be wary not to lock vital information or actions behind inaccessible doors.
At the end of the day, a healthy flow of communication between product, development, and design is the only way to find the best balance of accessible and creative. You'd be surprised how much component behavior is negotiable, especially with compliance on the line.
An awareness of accessibility requirements at all stages of the design processes is critical, but I find development shoulders a lot of the responsibility since we're the ones in the business of making design dreams come true. I have to admit, sometimes the dev magic really does make the impossible seem possible, and it's hard from the outside looking in to know what exactly takes something from "pretty simple" to "never gonna happen."
Final Thoughts
It seems inevitable that trendsetters in design and development will be forced to sacrifice accessibility to stay inventive and novel. Until W3C gets ahead of the curve and anticipates what kind of framework designers and developers will need for their next hair-brained scheme, those of us with more strict (legal) accessibility requirements will have to pick and choose our battles.
Will the internet keep forming new design patterns faster than W3C can keep up? Or will accessibility requirements stifle the creative and novel design we see breaking the mold?
Top comments (0)