Monday, June 9, 2014

Accessible Bootstrap Frameworks

This post originally appeared on the Algonquin Studios blog.

If you work much with accessibility, then you might consider the title of this post to be an oxymoron, a self-contradicting mess. Frankly, I tend to agree. Barring a compelling use case, I never start a project with Bootstrap and I resist including it when explicitly requested (so far successfully in nearly every case). Of a few reasons, accessibility is the biggest issue I have with it.

There are, however, a couple options to mitigate the accessibility mess that is Bootstrap.

I should note that this post is a follow-up to the Q&A after my talk at HTML5 Developer Conference, Selfish Accessibility, where I gave some advice about Assets which, at the time, was using Bootstrap 2 (it has since moved to version 3).

Assets.CMS.gov

Screen shot of Assets.cms.gov. The Centers for Medicare & Medicaid Services (CMS), a division of the US government (specifically HHS), has emerged as an unexpected champion of accessibility for Bootstrap and made its own framework, Assets (first announced in late 2012). This may not be a surprise to many when you consider CMS's role working with people who are older and/or in need of some form of medical assistance (equipment or services). Arguably, its constituency stands to benefit the most of any division of the US government.

Assets was just updated to use Bootstrap 3 (which should make many a Bootstrap user happy). Assets promises you:

Section 508 compliant, cross-browser compatible UI components that you can use in your accessible web site or web application. Assets is an accessible, responsive, modern framework.

If you are an organization that works with the federal government to build web-based applications for the general public, then it may be a no-brainer to use this framework. Arguably your Section 508 accessibility requirements are met to a high degree, and where the framework fails you may be able to make a case that you are using a government-sanctioned tool. It doesn't let you off the hook for more fundamental accessibility failures (color contrast, images as text, infinite scroll, etc.).

The accessibility statement identifies the profiles used for testing. The documentation page links to all the UI components, which is handy. Jennifer Sutton has also provided links to tests she made with the calendar widget over at the WebAIM mailing list (though she was using version 2).

There are some caveats. On the spectrum of Internet Explorer versions, it only supports version 8 and above (the last version, built on Bootstrap 2, also only supported IE8+). The files are served from a US government CDN, which while not bad in and of itself, should require you to test them to make sure it serves the files as well as a commercial CDN. For example, icon font FontAwesome is served via the Assets CDN, though you may want to compare against others given its ubiquity on the web.

The Assets documentation also provides links to a Medicare style guide and a Healthcare.gov style guide, both of which require a login to see, severely limiting their value to sub-contractors.

PayPal's Accessibility Plug-in

Screen shot of PayPal Bootstrap accessibility plug-in on GitHub. If you refuse to use anything from the US government, you can head to the other end of the spectrum and use the accessibility plug-in from PayPal.

According to PayPal:

This plugin adds accessibility mark-up to the default components of Bootstrap 3 to make them accessible for keyboard and screen reader users.

Because it's an add-on to your existing Bootstrap 3 code, it should just work. It will make the following default UI components accessible: Alert, tool-tip, pop-over, modal dialog, drop-down menu, tab panel, collapse, and carousel. You can pop over to the demo page and test it out with and without the plug-in (use a keyboard to understand the benefits).

As with Assets, this doesn't guarantee that what you build will be accessible. You still need to consider the same items I cite above along with many many more accessibility elements which cannot just be handled with a plug-in nor a checklist.

Related

The Canadian government has created its own framework, also intended to be accessible, usable, interoperable, mobile friendly and multilingual. The Web Experience Toolkit (WET) has just moved up to version 4.

While not a framework nor an accessibility add-on, the United Kingdom has a handy style guide to make all its gov.uk properties look consistent: GOV.UK elements

There may be hope for government web sites after all, though just don't try to use Section508.gov with a keyboard.

Update: July 7, 2014

Heydon Pickering has updated his Revenge.css to work with some Bootstrap shortcomings. If you aren't familiar with Revenge.css, it's a handy CSS file you can call via a bookmarklet to highlight accessibility issues in your CSS file (like removing outlines, or forgetting the :focus selector when you use the :hover selector).

2 comments:

  1. And, as ever, I wonder why organisations/people decide to fork bootstrap (meaning it'll go out-of-date unless devs actively work on keeping it in sync) or to make changes to bootstrap markup via a plug-in, instead of - in both cases - making pull requests on bootstrap itself. Serious question here...I've found the bootstrap team to be, like most other maintainers of a large complex repo, quite open to good pull requests provided that they're well documented, follow the preferred style, and pass unit tests (if it's JS stuff). Serious question, not just trolling...what are the barriers to contributing to bootstrap directly?

    ReplyDelete
    Replies
    1. That's a great question. I suspect in the case of the U.S. government, it's the perception of control (for it and implementors) and perhaps an (ego-driven) argument that government is better suited to meeting standards (Section508.gov demonstrates how this isn't true). Clearly I'm just speculating.

      For PayPal's solution, it's an add-on not a fork (correct me if I am wrong). It's easier to bring *existing* Bootstrap implementations to some level of accessibility via just another include, easing barriers to uptake. That doesn't explain, however, why this isn't also being rolled into ongoing Bootstrap development (via pull requests., bugs, etc.).

      Delete