Accessibility

I totally forgot about print style sheets

Aaron Gustafson recently sent a tweet to Indiegogo in which he pointed out that their order details pages aren’t usable when printed.

Image

When I saw this tweet it struck me, because I realized that it has been a long time since I have optimized a page for print or even spared a thought on checking.
Maybe it’s due to the constant resizing of our browsers and making sure that our sites work perfectly in all shapes and sizes or maybe it’s just because I rarely print web pages myself. Whatever it is, I totally forgot about print style sheets and that’s bad.

Optimizing web pages for print is important because we want our sites to be as accessible as possible, no matter the medium. We shouldn’t make assumptions about our users and their behavior. People still print web pages. Just think about articles or blog posts, recipes, contact information, and directions or real estate sites. Someone somewhere will eventually try to print one of the pages you made.

[See various tips and primer in link]

Accessibility: Allow users to control their environment

Opening links in a new window [or tab] allows users to explore related materials without losing contact with the originating site; removing link underlines makes pages cleaner and easier to read because underlines are distracting and interfere with letterforms; and creating fixed-width pages restricts line length so users are not forced to read long lines of text. However, each decision has the potential of causing usability problems for some users: When links open in a new window, users who rely on the back button to navigate the Web will not have access to that functionality; when links are not underlined, users who cannot distinguish colors may not be able to identify links; and when pages are set to a fixed width, users who need to enlarge text will be forced to read narrow text columns.

Don't Re-Create Browser Features (Text resize widgets, etc.)

I built text sizing widgets for years, every damn site. I was so proud of them too. It was a way of showing I care about users. It was all ego. As soon as I could start tracking clicks on those widgets I found they were not used. Even on sites I built for low vision communities.

Instead, a good design with non-hardcoded typefaces that is responsive and does not disable zoom was all I needed. In short, good development techniques and best practices. That handled most of my edge cases just fine. For the remainder, a little documentation in the form of simple, contextual help text.

Notice I am not referencing assistive technology. For the most part, those users don’t need your widgets, they have already obtained tools to work around a non-inclusive web.

[…]

Instead of custom widget, maybe help educate users on how to use their own web browser. Perhaps link to, or offer as pop-up help, quick instructions on how to scale text in the user’s current browser.

Now you will have educated a user. You will have armed a user to have a better experience across the whole of the web. You will have stopped selfishly building a widget for just your users and contributed to empowering all users.

What could be more inclusive than that?

Large, custom, accessible checkboxes and radio buttons on GOV.UK

Image

Early in the development of GOV.UK we observed in research how a majority of users would click on radio button or checkbox controls rather than on their labels, despite the fact that the labels are much bigger and therefore easier to click (see Fitt’s Law).

[…]

We reasoned that this was because users didn’t know whether or not they could click on the labels. Many websites don’t let you click on labels, so choosing to always click on the control is perfectly rational user behaviour.

[…]

First we thought we’d try to make it really obvious that you could click our labels, so we coloured them grey and made them respond to the mouse hovering over them.

We thought this would work, so we rolled out the design across services on GOV.UK. We saw again and again though in lab research that most users still clicked on the controls.

[…]

In our latest iteration we’ve replaced the native browser controls with custom ones, which all our supported browsers will get.

We’ve also removed the grey background, as it did not have the effect on user behaviour that it was intended to.