LibTechConf 2014 Presentation: We Are All Disabled! Universal Web Design Making Web Services Accessible for Everyone

This is the full write-up for the presentation I did at LibTechConf 2014, not including the Q&A section. There are slight differences from the actual presentation, primarily having removed the questions I asked the audience and in a couple of cases, adding further notes or source information. 

Have some slides:

Introduction

Insert the usual personal introduction.

A note on the ‘GO AWAY’ slide. This slide was stolen from @mreidsma, who in turn stole it from @adr, used to tell people that if they really want to go to another session, this write up will be available.

We’re here this afternoon to talk about making the web accessible, so let’s start with defining web accessibility.

What is web accessibility?

Here’s one definition, and what seems to be the most common one:

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.

Can you name the different types of disabilities? Here’s a picture [see no evil, hear no evil, speak no evil image] that might help you with the answer.

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?

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.

A Big Minority

We’re information professionals, so of course we love numbers. So here’s one:

According to the last US Census in 2010, 16.6% (29.5 mill) of adults (21-64) had a disability.

For the Canadians, Statistics Canada

Based on 2012 data from The World Bank, that’s approximately 2.4 million people.

The number of people with a disability is larger than any one group of ethnic or visible minority in their respective countries.

<aside> The Proof

USA (2010): Although comparing the total population (instead of an age group), 18.7% of the total population had a disability, and the largest ethnic minority was Black or African American at 12.6% of the total population.

Canada (2006): Using the data from the last census, 11.5% of total population ages 15-64 had a disability, and the largest visible minority was Chinese at 4% of total population ages 15-64.

</aside>

Okay, so we’ve established that a lot of people have a disability, but maybe your department doesn’t normally deal with anyone with a disability because that’s not part of the group of users. However, even in special libraries (where the audience is internal to an organization), you cannot always know the full extent of your audience, because there is bound to be staff turnover and people with disabilities that aren’t visible.

Guidelines & Legislation

Let’s go so far to say that you only have one disabled user. In most cases, libraries and other information organizations are legislated to be accessible regardless of the number of people with disabilities they serve.

United States

In the US, many people will have heard of Section 508 (stipulating that electronic information and technology need to be accessible), and will also know that it only applies to federal agencies.

However, Section 504 also has a clause that says

“No otherwise qualified individual with a disability […] be excluded from […] any program or activity receiving Federal financial assistance”.

Many states also have their own legislation that either simply establish the same regulation for anything state funding, or might extend the regulations further.

In addition to The Rehabilitation Act (which includes Section 504 and 508), there is also the Americans with Disabilities Act, which basically provides civil rights to people with disabilities much like the Civil Rights Act would apply based on race or religion.

There have even been some legal cases won against commercial organizations, such as the over $6 mill settlement Target paid in 2009 for their website not being accessible.

Canada

In Canada, the situation is a little different where only the federal government departments and the public institutions of Ontario are legislated to meet web accessibility guidelines.

However, Canadian legislation specifies following the Web Content Accessibility Guidelines, which has many more guidelines than Section 508 to define what is accessible.

See my blog post, Alignment of WCAG with Section 508 & Canadian Legislation, for a more detailed comparison.

Organization Level

Many libraries and other information organizations will also have policies or mandates that have to be followed relating to accessibility.

Simply Because

Nevertheless,

“Lack of statutes or federal laws should not exempt libraries from providing equivalent access to all; it should drive libraries toward it.” – Camilla Fulton (source article)

In light of that, regardless of legislation and guidelines or the number of people with disabilities, most information professionals I’ve met don’t need more of a reason than simply because we want to help.

How Do We Develop for People with Disabilities?

Now that we’ve established the basics of who and why, let’s move on to how.

While I’m using a website as the basis for this talk, I want you to think about how the general ideas might apply to other programs or services beyond websites, beyond even technology related things, maybe think about the information desk, an exhibit, or even story time.

Let’s start with the assumption that you want to redesign or develop a new website. This is a vast oversimplification of the whole process, but this seems to be true at many places when it comes to accessibility:

  1. develop the website,
  2. add or adjust things to work with screen readers,
  3. launch (may happen before #2).

While screen readers are frequently used by those with visual impairments, they are not the only type of assistive technology.

If you wanted to make a list of all the assistive technology that you need to consider, you first need to define the term.

What is Assistive Technology?

an umbrella term that includes […] devices for people with disabilities […] by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. – Wikipedia

To summarize, it’s a piece of technology that helps a person accomplish a task.

There are many different types of assistive technology, such as (each example with relevant image)

  • screen reader,
  • magnifier,
  • using the browser’s zoom feature, and
  • a pointing device that is not a mouse.

But wait, if assistive technology is simply technology that helps a user complete a task, then you also need to take into consideration:

  • keyboard only user,
  • or someone not using either a mouse or keyboard.

So here’s a quick question: how many of you regularly use a touch screen? That includes touch screen anything: phone, tablet, monitor, SmartBoard.

If a keyboard, mouse, or touch screen helps you to accomplish tasks, then we might say

All Technology is Assistive Technology – Sara Hendren @ablerism (source article)

Please stop and think about this for a moment, about how it applies to your work and your organization. How might this one statement change the development process for websites, technology projects, and other services.

Hendren goes on to make another point, while not new, is an important one:

There is no average or normal user.

We are not developing for a specific piece of technology, we can’t. There are too many potential devices (image: mobile devices) and ways people are using devices to do that. We aren’t even necessarily developing for people, but for potential situations. For example, room with different lighting might make something easier or harder to see.

So how can we do that?

The Solution?

“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 @rileyhuff (source article)

Riley-Huff was specifically referring to websites, but we should be scrutinizing our methodology in how we approach any of our projects.

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

On a side note, you will see similar terms, such as design for all. While a separate term referring to the design philosophy, it covers the same idea.

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

  • equitable
  • flexible
  • simple and intuitive
  • perceptible
  • minimizes errors
  • low effort
  • approachable and usable

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

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.

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 9 usability principles, and taking the keywords in a similar manner as with the original ones, they can be summarized as:

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

Putting Universal Design into Practice

At this point, let’s make the assumption that we think universal design is a good idea. What now? How do we put universal design into practice?

Understanding Your Users

One of the first things you might do is get a feel for how different users might interact with websites. You might try:

  • navigating without a mouse,
  • browsing with a greyscale filter, or
  • using a screen reader.

There are obviously a lot of other exercises you can try, even simple things like using your organization’s website on a small screen tablet or smartphone.

To assist with any development process, you might create user personas (image: template) to remind you about the different groups of people and their situations.

While this example (image) is for a course (Michel Miller being the name of the instructor), the user profile serves as a reminder when developing material that one of the users has learning and reading disabilities.

Sources to build the personas vary, but might be real people or looking at profile related statistics on your audience.

Being User Focused

Let us continue with the idea that you are redesigning or designing a new website.

Other early development strategies frequently focus on content and organization of the content. You want to go through (each with example image):

  • content inventory – create a list of all the content on your site and look at what to keep, revise and remove;
  • card sort – get users to sort the topics of your content into groups and provide labels, which can turn into the organization of your website; and
  • use cases (or task analysis, which is slightly different but similar).

These methods are only a sample of what should be part of your development process.

The idea here is that you want to keep your users the main focus and that you ask your users again and again, at all stages.

Card sorts are an obvious place in the early stage, but later on, you want to ask users about mockups and prototypes, running different types of usability tests.

Creating the Website

Once you have an idea of what will go into your website and how it might be used, you of course want to create your website.

Considering that you want your website to work across devices and browsers, the key strategies you should be applying are:

“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, 74% in fact, 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 (example screenshots).

I won’t go into detail on any of these practices, because each of these are sessions in themselves. Instead, I want to turn to some details that are more specific to web accessibility.

Accessibility Considerations

Media

I think most people by now are familiar with alt text, the attribute to describe images, and is the text that is shown when an image doesn’t load.

The idea behind alt text is that users should always have a description for anything that is purely visual, which is why audio and video should have transcripts.

Related to media, nothing on your website should ever autoplay.

Autoplay can lead to issues for those with specific medical conditions. Needless to say, you also want to avoid anything blinking or flashing.

You might be thinking that none of the video and audio play automatically on your organization’s website, but while it’s not video or audio, it doesn’t mean that you don’t have anything that autoplays.

Matt Anderson posted about 20 Great Public Library Websites about a year ago. Of those 20, as of last week, 18/20 had a carousel and 17 of them automatically changed the image.

I recently wrote a blog post titled, Death to the website carousel, inspired by the ‘Should I Use a Carousel?’ website because library and other public websites are rife with carousels or image sliders.

In addition to the frustration frequently experienced by users, I still haven’t heard of anyone making a fully accessible carousel. Check out that website if you need some convincing statistics and other reasons on why not to use a carousel.

Keyboard Accessibility

Actually, here’s one. Carousels frequently are not keyboard accessible. Try changing the image using the left and right arrow keys and see if you get the previous or next image in the carousel.

A website should be fully keyboard accessible, meaning that a user should be able to properly navigate and interact with your website using only a keyboard

Generally, that means you should be able to hit the tab key and go from one link to the next, through form fields in order, and never be trapped anywhere on your site.

Ideally, your users will be able to easily see which field (example screenshot) or link (example screenshot) they’re focused on.

Skip Links

It’s a small thing, but skip links allow screen readers and keyboard only users to skip blocks of content that are repeated on every page, such as the header and menu areas. They’re easy to code by adding a link (code example shown), such as ‘Skip to menu’ at the top of the page, and applying a CSS class to hide it from the visual user.

ARIA

Finally, we get to WAI-ARIA, the Accessible Rich Internet Applications Suite, or simply called ARIA by most. 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.

Many of the basic roles would normally be taken care of by the new HTML5 elements, such as <nav> for navigation, but the combination of browsers and screen readers have not caught up in properly implementing the relationships, so for now, many of the ARIA roles need to be added for simple things (code example shown) as well as whenever you have more complex interactions that happen (and you’re not using an accessible toolkit or framework).

Reference Material

Most developers will readily admit that they look things up all the time, and with web accessibility, that’s no exception. There are lots of resources out there, but here are a few that are particularly useful:

Testing Your Website

With some time and magic, at least a prototype website is created and you want to put it through some tests before you give have real world users put it through usability testing.

There are lots of tools to check your code and many people have their preferences. These are the ones I use:

Once you’ve fixed any errors caught by these tools, then you can go do your usability tests with those real world users.

For Your Content Creators

Finally, your website is complete and the only thing left is to add some content. At this point, you need to rely on other people to be the content creators. And we know that humans are the problem, because you can control code, but you can’t control humans. Nevertheless, you can mitigate problems by keep it simple.

When I train staff on adding content, I give them just a few, simple guidelines.

  • Use headers properly – I tell them to use them like they would in a report
  • Use descriptive links – pretending the only context a user has is what page they’re on
  • Describe Your Images – that is, use alt text
  • If you embed audio/video, add a link to it too – for example, if they embed a youtube video, add a link to the youtube page as well
  • Be clear and concise – because our users don’t want to read whole paragraphs to get the answer they want

That’s it. Five simple guidelines.

Putting It All Together

What you can or cannot do will really depend on your role, your CMS, and your organization, but maybe this can help guide you:

“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 (source)

So if all you can do is provide your content creators with guidelines similar to the ones above to follow, you’re already making your website content more accessible. You’ve taken one step forward:

“the goal of universal usability is to enable the widest possible range of users to benefit from information and communication services” – Ben Shneiderman (source)

Take Aways

I hope you weren’t disappointed. Today’s session wasn’t explicitly to tell you how to develop or code your website, but to help you think about web accessibility.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” -Tim Berners-Lee @timbernerslee (source)

Of course, it’s not about how to include users with disabilities, because if we all need assistive technology, then

“We’re all disabled” – Lennard Davis @lendavis (source book)

While there are a few considerations we might not normally think about, if you only take one thing away today, it’s this:

“Universal usability is simply good design.” – Jonathan Lazar (source book)

And I would say the same about universal design.

One thought on “LibTechConf 2014 Presentation: We Are All Disabled! Universal Web Design Making Web Services Accessible for Everyone”

  1. Pingback: LibTechConf Presentation: We Are All Disabled! ...

Comments are closed.