Making Web Services Accessible With Universal Design

This was presented as a webinar for the Education Institute on Thursday, January 22, 2015. This presentation is mostly an amalgamation of the Access 2014 and LibTechConf 2014 presentations. There are a couple of small sections (namely analytics, how ever did I forget about that?) that have been added, but a lot of it is recap for those who have seen my presentations before.

Slides

Web browser version

What is Web Accessibility?

We’re here today to talk about accessibility, but what is web 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)

Having established that, we might look at defining a disability. That’s actually a really hard task, but we can look at the different types of disabilities.

Types of Disabilities

• visual: other than blindness, this might also refer to people who have difficulty with judging distances and hand-eye coordination
• auditory: other than deafness, this might also refer to other hearing issues, such as having difficulty focusing on a single voice
• physical/motor: examples include not being able to grip something or problems with precise movements
• touch: namely this refers to a lack of sensation with touch
• learning: is a rather large umbrella term, but includes dyslexia and other reading disabilities, as well as dysphasia and related issues with writing

Why Should You Care?

Numbers

People with a disability are a minority, and not all of them need special consideration for web accessibility, right? While that may be true, you might be surprised by some of the facts.

Statistics Canada tell us that “10.1% [approximately 2.4mill] of working-age Canadians (15-64) reported a disability in 2012”

The number of people with a disability is larger than any one group of ethnic or visible minority in this country.

That’s a Big Minority

Policy & Legislation

In Canada, only the federal government departments and the public institutions of Ontario are legislated to meet web accessibility guidelines.

However, many organizations or at times, municipalities will also have policies or mandates that have to be followed relating to accessibility. Nevertheless,

“Lack of statutes or federal laws should not exempt [us] from providing equivalent access to all; it should drive [us] toward it.” – Camilla Fulton

And, while 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.”

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 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,
• serve all users, – not just those with disabilities, and I’ll talk more about this
• make sound fiscal policy, – since it improves efficiency and reduces costs while maintaining quality, avoids retrofitting, avoids inequitable solutions, avoids litigation; frequently fulfills grant/contract requirements – and
• add value to the institution. – because you have a better web content, it benefits more people (e.g. captions help people with varying language skills), is easier to maintain and update, 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 want 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 @whitneyq

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

This is a problem, because obviously, your service needs to be both usable and accessible.

Designing for Assistive Technology

Let’s also take a look at her point on “assistive technology”.

Say as part of your approach, you want to make sure your content 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?

Is there anyone who doesn’t use a keyboard or touch screen regularly?

At this point, you might realize that

All Technology is Assistive Technology – Sara Hendren @ablerism

We are not developing for a specific piece of technology, we can’t. There are too many potential devices and ways people are using devices to do that. We aren’t even necessarily developing for people, but for potential situations, because conditions including physical or environmental ones can be temporary.

So how do you design for accessibility, if that includes all technology?

Universal Design

What we need to do is change the way we think about accessibility,

“Move away from the approach of building separately for disabled users, and concern yourself with creating clean, beautiful, usable, and accessible websites.“ – Debra Riley-Huff

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

While not a new idea, Hendren also reminds us that

“There is no average or normal user.” – Sara Hendren

The solution would be to 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

The term was originally coined by the architect, Ronald Mace, so the principles tend to be based on physical space, but can be summarized with these key words:

• equitable
• flexible
• simple
• intuitive
• low effort
• approachable
• usable

Example

One of the most well-known examples is the wheelchair ramp.

Here’s a thought exercise, which I’ll give you a few moments to think about. Other than wheelchair users, what groups of people might need to use a ramp like this?

Other than wheelchair users, there are many other that find ramps useful or even necessary, such as:

• parents with strollers,
• seniors with mobility walkers, and
• anything else with wheels.

Many places now call it an “access ramp” or just “ramp” to reflect its greater, universal application.

Universal Design for the Web

Many parts of the website can be thought of the same way. Looking closely at the Web Content Accessibility Guidelines for example, we can see many guidelines that would apply not only for users with disabilities, but all users. Some examples include:

• each page should have a title,
• have consistent navigation,
• have a meaningful order to content,
• provide multiple ways to discover content e.g. links, search box, and
• captions or transcript of audio/video (good for example for ESL, different learning styles).

When developing for the web then, we can adopt many of the same principles for universal design as with physical spaces.

Whitney Quesenbery suggests usability principles, summarized as:

• solid,
• clear,
• helpful,
• usable,
• accessible,
• easy to understand, and
• designed with people in mind first.

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

Universal Design in Practice

Like any methodology, there is no one way. Design, after all, is not an exact science.

When designing or reviewing tools or services, I suggest doing as much as is practical.

Exercises

You might try an empathy exercise, having yourself and others simply experience what it is like to explore the web using different technologies including a screen reader, only a keyboard, in greyscale, with a very small screen.

Challenges

Keep in mind that 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

Ask Your Users

All the more important then that you do 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.

You will want to use various usability methods including:

• 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
• content inventory – where you create a list of everything and decide to keep
• card sort – where you get users to sort topics of your contents, helping to build the navigation
• task analysis – analyzing the process to complete a typical or expected task

Having the results on hand or on a wall will help keep your users in mind. This is not an exhaustive list, but a good place to start. Check out usability.gov for more methods and details.

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.

Approaches

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

• mobile first,
• progressive enhancement, and
• responsive design

“Mobile forces you to focus.” Luke Wroblewski @lukew
Mobile first means you have to prioritize and focus everything including content, interactive elements, and layout.

Using progressive enhancement means you focus on the basics and

“Worry about the less capable first.” @Swwweet

From there, you add any fancy bits, typically using JavaScript or third-party modules, where you want to consider using accessible ones, particularly UI frameworks, such as jQuery UI.

Some seem to believe that this method means you’re always focused on developing for older or simpler browsers, but that’s not true.

“Progressive Enhancement moves almost all of our dev time and costs to newer browsers, not older ones.” @scottjehl

Additionally, your site is more likely to load quickly, especially if you use specific packages, such as adaptive images or picturefill.

Most mobile users won’t wait more than 5 seconds for a page to load. If you think about it, 5 seconds is actually a long time in terms of page load.

Finally, it makes sense that you would present more information to those who can see more on their screen at once, which is where responsive design comes in.

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 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 comforming to a good set of guidelines, such as the 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

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.

Reference:

• ARIA for the Spec Impaired by @gollydamn
• Using ARIA in HTML Recommendation Table

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, and I’ll talk about this again later.

Audio should have transcripts.

For videos, transcripts will also work, but should have captions,
and ideally, a descriptive audio track (example video).

One of the most problematic issues (and irritating too) is media that automatically starts playing.

You might think that the no autoplay guideline is very obvious.

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

• 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 not as telling when I last did the same exercise with the list of top 20 public library websites, and the result was that

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

This is why, at some point, I wrote a call to action to bring

Death to the Carousel
Inspired by shouldiuseacarousel.com
By the way, this is inspired by should i use a carousel dot com, where I wrote a blog post about the issues carousels typically have including frequently a lack of keyboard accessibility.

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.

Testing and Assessment

Tools

To assess your tool or service, you can use automated methods or tools.

• frameworks e.g. QuailJS, API based Tenon.io
• HTML Codesniffer (bookmarklet) – check against WCAG
• WCAG Contrast Checker
• WAVE Toolbar – view a website as text-only, outline only, etc.
• W3C Web Accessibility Tools list – for more

There are also simulation tools allow you to simulate certain conditions or environments. For example,

• VisCheck which processes images to simulate colour blindness. (Vischeck also provides a tool called Daltonize, which attempts to correct images.).
• Fangs, a Firefox plugin, which emulates a screen reader by providing what would be read in text form

Analytics

Numbers can’t tell you why, but they can help your assessment.
For example, numbers on visits and bounces can help you decide what to further assess, what’s popular, or what’s hard to find.

Rather than pure numbers, trends from analytics can be very helpful. Usage throughout a day, week, or year can help you decide on when to make changes, or promote things. It might even indicate when you’re more likely to get users for your usability tests.

In particularly, heat maps are good indicators of what people are looking for and where.

User Testing

However, numbers and tests is not an indication that your website is actually accessible or usable. Nothing can replace actual user and usability testing throughout development.

This is where usability testing comes in, which can be as simple or complex as you make it.

Simple ones include a “5 second test” where for example, you ask a user where they might click on a home page given a specific task. I also want to reiterate that testing and assessment should not all be done at the end, but throughout the process. The “5 second test” I’ve described is a great test to do while you’re still at the design stage.

More complex usability testing might involved scheduling specific individuals to answer questions and complete tasks in a lab setting where audio and video are recorded in a longer session.

Nevertheless, user testing can also be something in between. Guerilla testing is very popular whereby a laptop is setup with screen, video, and audio recording in a small area of a high traffic area, asking users who pass by to sit down for 10-15 minutes.

If you have some money, but not the time and in-house resources, there are lots of companies that will run usability tests for you.

If you want to specifically have disabled users test your service, I encourage you to collaborate with another department or team. If that’s not possible, Canadian organizations, such as the Vision Impaired Resource Network (VIRN), will do accessibility assessments on websites for a fee.

Training and Documentation

With the rise of the 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] You can give your staff resources, such as this alt text decision flow chart to help them.
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.

What you can or cannot do will really depend on your role, your CMS, and your organization, but

“I’ve learned that what matters […] is an actionable process — possible to use, adapted to the company’s culture and financially effective.” – Marcin Treder @marcintreder

An accessibility statement help you to document your outcomes and clarify for users what to expect. This statement is where you might also write a short explanation and list the impact of your third-party services.

For guidelines on writing an accessibility statement, take a look at

• 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

If you want to see what others are doing, take a look at

• Penn State University Libraries Web Accessibility Statement
• Toronto Public Library Accessibility Policy
• University of Oxford Accessibility Statement

Take Away

Alright, I know that was a lot of information, so if you missed any of that, don’t worry, my slides will be posted and the recording will be available for you to review.

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. Think about your web services, but beyond the website, what about catalogue or discovery layer, what about the online content or documents you provide?

“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

So, let’s build services that everyone can use.