I was reading the article Advocating for a Compassionate UI from Rally Health, a tech company who runs a benefits portal for my insurance company. I was reading it specifically because I’ve had various accessibility issues with their website and I wanted to see what their thoughts were regarding accessibility.
I found some of their arguments to be interesting but not compelling. For example, they talk about how accessibility needs are more prevalent than browser marketshare:
It might surprise you to see that many types of disabilities are more frequent than browsers typically given first-class support from developers and product owners. There’s no sense in supporting IE 11 if you haven’t already given full support to the colorblind and those with visual impairments.
One problem with this line of thinking is that many reasons why people prefer to use alternate browsers is because they have extension ecosystems which allow them to adapt the web to their accessibility needs. For example, I vastly prefer to use Firefox, largely because it has extensions which allow me to address some of my motor and attention dysfunctions (I run an ad blocker for a reason and it’s not to screw over publishers!), and many of the very features they talk about are things that browsers-which-aren’t-Chrome have support for, such as being able to override color schemes and input methods.
Unfortunately, because Firefox doesn’t enjoy first-class support anymore, many, many sites break on it now, and those sites claim to be “accessible” because they support a handful of Chrome-specific accessibility features (which still don’t actually work well with adaptive technologies and the like). Even if more people knew about the accessibility features and add-ons that Firefox offers, they wouldn’t be able to use it as their full-time browser specifically because so many sites break on it.
The web itself is a platform; targeting a specific browser is shortsighted and terrible, and leads to a vicious chicken-and-egg cycle. Supporting marginal browsers is a really good proxy for supporting accessibility, as well. One of the things I do when I design a new site is to make sure that it’s usable from text-only browsers like lynx and w3m; I figure that if it works there, there’s a pretty good chance it’ll work on anything non-Firefox. (I also test on Safari, since that covers the parts of the WebKit universe I care about. Typically if something works on Safari it’ll work on Chrome, but the opposite is not true.)
There’s a few other things that are troublesome about that Rally article; for example, it talks a lot about visual accessibility, but uses medium-gray text and light-orange links (with no underlines!) on a white background.
Rally’s site itself also makes use of a bunch of things that fly in the face of this advice:
Designs, implicitly or explicitly, often require the use of custom elements such as dropdowns to allow for greater control over the appearance of the UI to match the desired brand guidelines. It’s often possible to leverage CSS to reskin native browser controls to match the required designs, but when that’s impossible, you may need to create a custom component.
Push back against these custom components as strongly as possible in favor of their native browser counterparts. The native implementations already support all the required accessibility features, and replicating that in a custom component will not be a trivial task. For reference, see the keyboard interactions that a collapsible dropdown needs to support to achieve AAA compliance.
When first signing in from a new browser, it prompts you for a one-time code. This one-time code entry is done using a custom control, that is not very respectful of the fact that people make typos.
Many elements within their frontend framework are based on dynamically-created, <div>-based components which do not respect tab cycling or browser-native autocomplete, and which move around as pages fill in, which messes both with my focus issues (hello, ADHD, listed as the top single “market share” on that chart!) and with my motor issues (I really hate having to use the mouse for things like that).
To be fair, this isn’t limited to Rally Health’s site. It seems like every single healthcare-related website is like this lately; PRIDE Study is particularly egregious about these issues as well, where their web forms are very much Designed For Mobile™ and involve a lot of scrolling (often without it being clear where one is supposed to scroll to) and commits many other accessibility sins, such as:
- Making checkboxes and radio buttons look the same
- Not having labels act as click targets for their respective controls
- Not supporting tabkey selection
- Forms done as dynamically-animating, changing “single page application” stuff when it isn’t necessary or desirable
- Having entire sections of forms appear or disappear dynamically based on the selections you’re making (without any indication that they’re going to have such side effects)
The web has an input problem. Please, people, stop reinventing the wheel the long, and wrong, way around.
Top comments (2)
This is a very interesting subject and a very valuable perspective on it. I'm in the middle of building an app builder for Health & Safety and want to ensure the accessibility of things built on it. Not easy in that case for many of the reasons you list here as broken on other sites.
Generally-speaking, if you use built-in browser behavior (standard HTML forms, minimal/no use of javascript except to add functionality on top of the built-in browser behavior), you'll already be way ahead of most modern web developers in terms of accessibility and compatibility.