Access 2014: We’re All Disabled! Part 2: Building Accessible (Web) Services with Universal Design

This was presented at Access 2014 in a half hour time slot, so I was pretty tight on time. Recording of the stream should be available on the Access Conference Website at some point.

Slides

https://speakerdeck.com/cynthiang/access-2014-we-re-all-disabled-part-2

Presentation Slides

Introduction

Morning everyone. I hope yesterday’s panel on usability and accessibility got you thinking about how you might improve your web services. This presentation should provide some broader context and more of a quick overview.

Before we really begin, I’m curious to know, how many of you saw, watched, or read the retroactively named, Part 1 of my presentation from earlier this year? Either from LibTechConf, or Code4lib?

For those of you who have, I’ll try not to bore you. For those of you who haven’t, don’t worry, I’ll cover the most important points from Part 1.

What is Accessibility?

Okay, so we’re here to talk about accessibility, but what is accessibility?

One definition, and what seems to be the most common one is that

Web accessibility means that people with disabilities can use the Web. – W3C Web Accessibility Initiative (WAI)¹

With a working definition, we can then ask:

Why Should You Care?

People with a disability are a minority, and not all of them need special consideration for accessibility purposes, right? While that may be true,

The number of people with a disability is larger than any one group of ethnic or visible minority. This is true in both Canada and the United States.

That’s a lot of people.

Many organizations also have guidelines or policies around equal or equivalent access to all users, and depending on your location or type of organization, there may also be legislation that applies.

You might be convinced, but what about others?

Getting Buy-in

People frequently ask me how to get buy-in from others, because they might be convinced that we should care about accessibility and do something about it, but too often, accessibility is put aside because it’s too difficult, time consuming, or due to a belief that “accessible websites are ugly.”

On a side note, this last excuse is not true. I mean yes, some accessible websites are ugly, but in the same way that some websites are ugly regardless of the level of accessibility. If anything, the most accessible websites I’ve reviewed or worked on have been fairly pleasing to the eye. Just check out gov.uk

To start, maybe we can pull the this-is-what-experts-say card. After all,

[It is] well known among web developers that websites that are accessible are also much more usable for everyone. – Mohammad Eyadat and Jeff Lew²

If that’s not enough, there are numerous reasons you can present as benefits for putting into practice the methodologies presented, including that they:

• reflect institutional mission, leadership, and values, – okay assuming your institution has something about equal access
• serve all users,
• make sound fiscal policy, – since it improves efficiency and reduces costs while maintaining quality, avoids retrofitting, inequitable solutions, litigation; frequently fulfills grant/contract requirements – and
• add value to the institution. – because you have a better website, it benefits more people (e.g. captions to help people with varying language skills), loads more quickly in browsers, requires less bandwidth, is easier to maintain and update, tends to have a higher return in search engines, and higher compatibility with various software and hardware.

Which boils down to your service being more:

• findable,
• accessible,
• usable,
• shareable,
• efficient, and
• collaborative.³

Of course, knowing why doesn’t tell you how (to approach accessibility).

Approach to Accessibility

Whether you or your team wants to, or because you’re told to, half the battle seems to simply be figuring out your approach.

If, like many others, you see accessibility as something at the end of a checklist, then that’s when you’ll deal with it. However, at least two usability/accessibility experts tell us to:

Avoid the peanut butter approach. – Sarah Horton & Whitney Quesenbery⁴

This is actually a reference to Lewis and Rieman, who tell us that:

It just won’t work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter.  – Clayton Lewis and John Rieman⁵

Peanut butter is tasty, but not necessarily a big help in this case. [stuck in a jar picture]

Quesenbery also tells us that:

Accessibility often gets pigeon-holed as simply making sure there are no barriers to access for screen readers or other assistive technology, without regard to usability – Whitney Quesenbery @whitneyq⁶

Designing for Assistive Technology

This is a problem, because obviously, your service needs to be both usable and accessible. But let’s also take a look at her point on “assistive technology”.

Say as part of your approach, you want to make sure your service is accessible to all assistive technology. You start with ‘screen readers’ on your list,  and do some searching and start adding, other ‘text-to-speech’ software, ‘screen magnifiers’, ‘joysticks’, what about ‘mobile devices’ with the added accessibility features? What about ‘keyboards’ for keyboard accessibility?

At some point, you might realize that

All Technology is Assistive Technology. – Sara Hendren @ablerism⁷

So how do you design for accessibility, if that includes all technology? You don’t.

Universal Design

What we need to do is change the way we think about accessibility, and move towards universal design.

“Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.” -Ron Mace⁸

Accessibility is simply one piece of the puzzle along with standards & best practices, usability, user experience, and more.

Another way to think about it is that

“Whereas [universal design] is a design methodology (similar to user-centered design), [accessibility] is its most commonly associated metric.” – Andrew Maler⁹

Of course, the question still remains, how do you implement universal design?

Building Universal (Web) Services

Back to our question, how do we build universal (web) services?

Honestly, the best answer I can give you is that

It is important for designers to formulate and adhere to usable design processes and guidelines throughout the entire cycle of development so that the product or service is accessible and universally usable for all. – Constantine Stephanidis¹⁰

I realize that’s still a very vague answer. So let’s change the question. If someone came up to me and said

Tell me, exactly what do I need to do to make my new website universal?

Think About & Ask Your Users

I would probably still start with the broader perspective and reminder that you need to be doing the different types of exercises, tests, and studies, whereby you get your users involved as much as possible.

Throughout the process, the idea is to keep in mind that your users and the way they access and interact with your services are very diverse. Thus, you are faced with three major challenges:

• tech variety: hardware, software, network;
• user diversity: skills, knowledge, disabilities, personality (e.g. exploratory vs. cautionary), environmental conditions (mobility, sunlight, noise), literacy, culture, etc.; and
• bridging the knowledge gap: between what users know and what they need to know.¹¹

Usability and user experience exercise or studies in the early stages can help you with the second and third challenges. You might

• create user personas, – create fictional people (though usually based on aspects of real people) that represent major user groups of your audience, and I would please ask that you include someone with a disability here;
• do a content inventory, – create a list of all the content on your site and look at what to keep, revise and remove;
• do a card sort, – get users to sort the topics of your content into groups and provide labels, which can provide the information architecture (navigation and organization for what you’re building); and
• create use cases (or do a task analysis, which is slightly different but similar).

Having the results on hand or say on a wall will help keep your users in mind. This is not an exhaustive list, but a good place to start.

Developing Your Service

As an organization, at some point you’ll likely (hopefully) have gone through a branding exercise, where you set the style and layout of all your communications including business cards, letterhead, print outs, and the website.

Everything I’ve mentioned up to this point should inform and allow for some mockups, wireframes, and decisions to be made about the basic layout and possible categories or types of content.

When developing a website, you can tackle some of the technology challenges by using these key strategies:

• mobile first,
• progressive enhancement, and
• responsive design (which Jamie spoke about yesterday).

I won’t get into any of these because each one is typically one (or more) session on its own, but these are not new practices anymore, so if you’re not familiar with them, there is certainly a lot of material for you to read, some of which I’ve linked here.

To make things more efficient and consistent, be sure to use (or at least consider using):

• well structured code,
• style guides, e.g. Normalize CSS
• pattern libraries, e.g. UI Pattern Library by GVSU
• polyfills and other helper libraries, e.g. picturefill
• APIs (possibly even building your own), e.g. SFU LIbrary API
• testing frameworks or set of evaluation tools, e.g. QuailJS and
• good documentation (which yes, will require some writing time on your part) e.g. Phabricator.

Some “Special” Considerations

While making use of best practices and conforming to a good set of guidelines, such as the Web Content Accessibility Guidelines (WCAG), (along with everything else) should be enough, there are a few considerations that I want to cover because they are commonly missed or not thought about.

Let’s start with

Keyboard Accessibility

Websites should always be fully accessible by a keyboard. Interactive elements should be navigable and controllable by keyboard, keyboard shortcuts should not override default behaviour, and users should always know where they are.

For example, visual cues for input focus help your users regardless of whether they only use a keyboard or not, but are necessary for keyboard only users.

Skip Links

Ideally, your source order actually has your menu below your content, but if you’re constrained, skip links are useful for both keyboard only, and screen reader users. Skip links are simple links that allow users to skip repeated parts of your website, such as your header or menu.

ARIA

The role attribute that you see as part of the nav and main content div is part of the Accessible Rich Internet Applications Suite, or ARIA. Basically, it’s a way to add attributes to your code to make your site more accessible by telling a screen reader what ‘role’ your elements play.

So, “navigation” says this is where the main menu or navigation is.

You need to do some research on when to use these, and I have some ARIA resources listed.

Media

Last but not least, let’s talk about media. Media should have a text alternative. This is generally fairly straightforward.

For images, most people are familiar with alt text (example image and text), and I’ll talk about this again later.

Audio should have transcripts.

Videos should have captions, and ideally, a descriptive audio track (example video, NEED 7 minutes left). Alternatively, transcripts will also work, particularly if there is descriptive text.

One of the most problematic issues (and irritating too) is media that automatically starts playing. You look at me like you don’t believe me (image), incredulously you think, audio and video don’t autoplay on your website, because that would be ridiculous.

Except, less than a year ago, a list of top 10 academic library websites and when I checked last week,

• 6/10 had a carousel (which is less than I predicted)
• 5/6 autoplay

I’m not trying to pick on any of these particular websites, but simply used this list as a way to survey the landscape (so to speak).

It’s actually also not as telling as earlier this year when I looked at the list of top 20 public library websites, and the result was that

• 18/20 had a carousel
• 17/18 autoplay

So, I say,

Death to the Carousel¹²

I wrote a blog post about the issues carousels typically have earlier this year, where I note that lack of keyboard accessibility is common as well.

Okay, I admit that it is possible to create an accessible carousel, and they already exist (such as slick), but they are rarely used, or used in an inaccessible manner. I’m not actually telling you never to use them, but to really think hard about how and why you’re using one.

Evaluating Your Service

I mentioned a testing framework earlier, QuailJS, and there are others, sometimes built into software, such as Eclipse. You could build your own set of automated tests, but if you’re not comfortable with testing frameworks, you could choose a set of assessment tools, of which there are two types.

Simulation tools allow you to simulate certain conditions or environments. For example, VisCheck takes images and simulates colour blindness. (Vischeck also provides a tool called Daltonize, which attempts to correct images.). There are also screen reader simulators, such as Fangs.

Evaluation tools allow you to check conformance to guidelines. For example,

• HTML Codesniffer (bookmarklet) – check against WCAG, including when logged in
• WCAG Contrast Checker (Firefox plugin)
• WAVE Toolbar – view as text-only, outline only, etc.

(As Jeff covered yesterday,) Passing all of these tests does not mean that your website is actually accessible or usable. Nothing can replace actual user and usability testing throughout  development.

Remember when I talked about getting buy-in? Invite staff to watch user testing, and if that’s not possible, playback meaningful clips of what users say and do at a meeting and/or post them on your intranet. When you’re trying to convince staff of certain decisions, user voices are frequently the most powerful evidence. By posting your user results and other deliverables, such as mockups, you get the added bonus of being transparent in your process.

Guidelines for Your Content Creators

With the rise of the Content Management Systems (CMS), fewer organizations have a single person writing content for the website. When staff in an organization are restricted within their roles on a CMS, there is no reason that staff members should not be empowered to write and edit the content for the areas they are responsible for, and fix minor errors in other areas.

While you cannot control what other people write, you can encourage best practices by providing a few simple guidelines. By giving staff examples and resources, you can build content best practices into the writing process.

1. Be clear and concise – because users don’t want to read whole paragraphs to get the answer they want
2. Use headers and tables properly – I tell them to use headers like they would in a report, and tables should only be for displaying data (not for layout purposes)
3. Use descriptive links – pretending the only context a user has is what page they’re on
4. Describe images if needed e.g. alt text decision flow chart
5. Make and choose videos with captions, and add a link if you embed them

Emphasize that the guidelines are for everyone’s benefit, and that the accessibility and usability of content is a shared responsibility.

Accessibility Statement

Now that your staff have some guidance, what about your users? While not required, one of the great ways to be transparent and show your organization’s efforts in supporting equitable access is to have an accessibility statement.

It also helps to clarify for users what to expect depending on how much of your service relies on third-party services.

WCAG includes a section on writing conformance claims, and the Access 8878 site also provides a template based on the UK’s BS 8878 Web Accessibility Code of Practice

Take Aways

Alright, I know that was a lot of information, so if you missed any of that, don’t worry, my slides and everything I’ve talked about today will be posted on my blog.

While it’s important to take best practices into consideration and put sound methodologies into practice, if you leave here with only one thing today, it is that we should all be creating and building our services (not just web services) with universal design in mind.

Please think about how universal design might apply in all areas of your work, because

Until people find themselves in a situation where they are disabled due to their surroundings, they cannot fully appreciate how the built and virtual environments can throw obstacles in their paths – and indeed, profoundly affect their quality of life. – City of Calgary¹³

Luke Wroblewski even encourages us to design for

One Thumb, One Eyeball – Luke Wroblewski @lukew¹⁴

I mean after all, if we all need assistive technology, maybe it just means

We’re all disabled – Lennard Davis @lendavis¹⁵