• Thank you, MNsure, for giving me one more reason to hate ARIA

  Dec 19, 2015

  As a member of the accessibility community, I have the pleasure of getting to work with a wide variety of folks, all of whom approach accessibility with a somewhat different mindset. There are those, for example, who feel that accessibility is more of a technical challenge, an exercise in ensuring mechanisms exist for technologies like screen readers to understand what’s happening on any given web page. Others approach accessibility from a more user-centric standpoint, can users of all abilities understand and control the page? Most though, including myself, fall somewhere in the middle of that spectrum. As I write this today, however, I’m approaching accessibility from the perspective of an extremely frustrated blind guy who just wants to get something done and can’t.

  The problem

  Like many Americans, I'm opting to change my health insurance coverage due to rate increases with my current plan. My state, Minnesota, has a resource, a marketplace, called MNsure which allows people in my situation to search for and compare plans. Health insurance is pretty overwhelming, what with the myriad of options out there, and so I was excited to give this resource a try. Unfortunately, the more important aspects of the site are virtually unusable by screen reader users, a situation ironically caused by poor implementation of standards that were designed to help sites like this be more accessible in the first place.

  A super non-techie explanation of ARIA and why it matters here

  According to the W3C, the folks that make the standards that enable us to have a World Wide Web, ARIA is:

  WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Currently certain functionality used in Web sites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse. WAI-ARIA addresses these accessibility challenges, for example, by defining new ways for functionality to be provided to assistive technology. With WAI-ARIA, developers can make advanced Web applications accessible and usable to people with disabilities.

  To put this in plainer language, this means that ARIA provides a way for developers to take really complex webpages, such as those with constantly updating information, and make them more understandable to screen reader users without sacrificing visual design or functionality. Pretty cool right? One of the more powerful aspects of ARIA gives developers the ability to force a screen reader to output specific information immediately, even if the screen reader is currently in the process of reading something else on the page. While this might come in handy in certain cases, such as a chat or messaging application, it can have a serious impact on a user’s ability to read page content since the screen reader will interrupt whatever it’s doing in order to read whatever information the developer wants to force through. Getting back to MNsure (remember MNsure?), they are using an ARIA technique to provide extra information about links and form fields throughout the site. Examples include

  • "enter date in mm/dd/yyyy format"
  • "you can limit the number of plan listings"
  • "You can view more features about this plan",
  • "clicking this link will take you to the provider's web site where you can search for a provider".

  While all of these messages provide additional information and context, MNsure has implemented this in such a way that this additional text immediately interrupts the screen reader when encountered. This means that when reading through a page, I hear things like “You can view more features and details about this plan” but I have no idea what plan it’s actually talking about. The reason for this is that while the screen reader would normally read the link correctly, ARIA is being used to interrupt the screen reader from reading the link, so that it can read the descriptive messaging in its place. “Enter date in mm/dd/yyyy format” is helpful to know, but not when it’s done in such a way that prevents the screen reader from telling me what kind of date it wants in the first place – does it want my birth date? Coverage date? Today’s date?

  What we have here is a situation where something that was developed to enhance accessibility, was used inappropriately and has wound up totally degrading it. Unfortunately, as the end-user, I don’t have a way to prevent this from happening. Put another way, even though it’s my screen reader, the developer has more control over it than I do .

  Where to go from here

  When things like this happen, and they sadly happen more often than one might think, it's hard to figure out where to go, or what to do. When I mentioned this particular situation to a friend, their response was, "why don't you submit feedback, so that the issue can be fixed?" That's a great idea and normally I love submitting feedback and doing what I can to help make the web a more accessible destination, however right now, I'm needing to shop for insurance and I really don't want to get side tracked by trying to figure out how to submit feedback. Put another way, yes I can do this but right now, this isn't going to help me complete the task that brought me to the site in the first place. So I call, and I wait on hold because as much as my call might be important to them, I can't help but feel that my experience as a blind user of their site is certainly not.

  I mention in the title of this post that this gives me one more reason to hate ARIA. As I write this, I realize that it’s not ARIA that I truly hate, but the hap-hazard way it’s often implemented. When I think of ARIA, I think of an extremely sharp knife. When used properly, it can be a fantastic aid, but when used incorrectly, it can cause incredible harm. ARIA has the potential to give screen reader users access to all kinds of dynamic information. If used incorrectly though, it can cause incredible harm as evidenced by my particular experience. If you’re a screen reader user, I would encourage you to learn more about ARIA and the kind of control it allows developers to wield over your interaction with web applications. Maybe not an in-depth technical understanding, but enough to possibly know what’s going on when things aren’t behaving the way you might expect – maybe I should do a blog series on this? If you’re a developer, please please please be careful with ARIA. Yes it can provide fantastic solutions to complex accessibility problems, but it can also create complex accessibility problems where simple solutions would suffice. Understand the impact of what you’re doing, there’s plenty of resources out there to help with this including many kind folks who use the technology every day and can sey “hey, this isn’t working the way I expect it to.” So please ask, learn, grow and help make whatever experiences you’re creating on the web usable and enjoyable by all.

subscribe via RSS