This was presented as a guest lecture at Langara College for the Fall 2015, LIBR 2411: Library Technologies and Information Management course in the Library Technician program. The presentation included a number of discussion questions and exercises, which are still noted but the wording has been edited. Please also note that sources are listed in the deck and typically not listed in the write up.
Original Slides on GitHub Pages
Definition
Can someone tell me what web accessibility means to them?
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, normally we might consider 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?
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
Numbers (or Why Should You Care?)
Frequently, people ask why they should care about accessibility. Here you are, sitting in class, and the person at the front says “Listen up, this is important”, but how often does that actually make you care?
So let’s have a simple exercise: I want everyone to stand up. (Everyone sits down minus 10%). Look around, because these are your friends, your classmates, your future colleagues and theoretically, this is the number of them just in this one classroom that have a disability.
Statistics Canada tell us that
10.1% [approximately 2.4mill] of working-age Canadians (15-64) reported a disability in 2012.
In the US, the numbers tell a similar story. According to the US Census in 2010,
16.6% (29.5 mill) of adults (21-64) had a disability.
The number of people with a disability is larger than any one group of ethnic or visible minority in this country.
Policy & Legislation
In Canada, only the federal government departments and the public institutions of Ontario are legislated to meet web accessibility guidelines. In the United States, the federal mandate stems from the Americans with Disabilities Act, but specifically around web accessibility, federal funded entities must comply with Section 508 of the Rehabilitation Act, and there are numerous states that have their own laws.
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 libraries from providing equivalent access to all; it should drive libraries toward it. – Camilla Fulton
Getting Buy-In
Everyone wants buy-in for what they do in their organization. With accessibility, not only do you want buy-in from your teammates, but from the top-level down.
If the numbers and legislation aren’t enough, there are a lot more reasons you can present as benefits, including that it:
- reflects institutional mission, leadership, and values,
- serves all users, – not just those with disabilities, and I’ll talk more about this
- makes 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
- adds 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 library content and services being more:
- findable,
- accessible,
- usable,
- shareable,
- efficient, and
- collaborative.
It’s best if you can get accessibility integrated from the first phase, making everyone accountable, and I’ll touch on this again later.
Oh, and no excuses about accessible websites looking ugly. Some of the best looking sites I’ve seen are accessible. Just check out the U.S. Department of the Interior.
By the way, the tumblr I got this from lists a bunch of accessible websites, some testing tools, and some interesting articles.
Designing for Assistive Technology
Assuming at this point, we have buy-in, we’re going to make our website accessible. How do we do that? Well, let’s also assume that we have a working website, but we want to make sure it works with the technology that those with disabilities use. This group of technology is usually referred to as assistive technology, but what is it?
Defining 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
Unfortunately, I don’t know that an umbrella is going to help us here.
Considering Assistive Technology
When I ask you to think of assistive technology, what do you think of?
Examples include:
- screen reader,
- text-to-speech,
- screen magnifier,
- pointing devices, such as joysticks.
Okay, so you have your list of technology. If we break it down into inputs (the things we use to give computers commands) and outputs (the way the computer talks back to us), then we might get a big table that looks something like (the matrix of inputs and outputs).
But wait, if we are talking about a device that helps us complete tasks, then we all use them, every day.
Who hasn’t used a keyboard even just today? Or used a touch screen?
If you include keyboards, and touchscreens in the list, then we might say that:
All Technology is Assistive Technology – Sara Hendren @ablerism
That means that
We need to change the way we talk about accessibility. … We can reframe accessibility in terms of what we provide, not what other people lack. – Anne Gibson @kirabug
Universal Design
Rather than thinking of accessibility in isolation, we want to think about how to design anything, websites included, so that everyone can make use of what we build.
One of the most well-known examples of universal design is the wheelchair ramp.
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
This is nothing new or radical, it’s simply a different mindset. Rather than singling out people with disabilities, we want to think of them as just one group of users in our userbase.
So, when creating for the web, you want whatever it is you build to be:
- solid,
- clear,
- helpful,
- usable,
- accessible,
- easy to understand, and
- designed with people in mind first.
These are just general guidelines for you to keep in mind.
You also want to keep in mind that you are faced with three major challenges:
- technological 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
While what I talk about will touch on some of the other topics you’ve already covered and will be covering in the coming weeks, such as user experience and usability testing, I will try to focus the rest of this talk on development, particularly in regards to accessibility and the technological challenges.
With that in mind, let’s assume you know what you want to build and who you want to build it for.
Approaches
When developing a website, you can tackle some of the technology challenges by using these key strategies:
Minimal Load Time
According to HTTP Archive, the average website is 2.2 MB, which means over 6 seconds (if Keynote statistics are to be believed). When you think about it, 6 seconds is a long time for a website to load.
Most mobile users won’t wait more than 5 seconds for a page to load.
Even if it’s less than that,
Two seconds may not seem like a long time, but consider that users can spot—and are bothered by—performance delays as short as 300 milliseconds. – Scott Jehl
One of the ways to positively affect your load time is…
Progressive Enhancement
Using progressive enhancement means you focus on the basics and
“Worry about the less capable first.” @Swwweet
When building a website, the most basic component is the content, especially the text and the few necessary images. Then, add colours, layout, and other presentation aspects, but do it with the lightest technology. The idea here is to make it work in all browsers and platforms. Once you’re sure of that, add the fancy bits, possibly making it load after the page has already rendered to make it even faster.
Another way to improve your load time is…
Mobile First
Mobile first can help with a lot more than just load time, because
“Mobile forces you to focus.” Luke Wroblewski @lukew
Mobile first is about prioritizing and focusing everything, including content, interactive elements, and layout, so that you can fit the most important parts on a mobile screen. It’s almost like progressive enhancement, where you start with the basics and most important and then you add to it. So you should see the most important content on a small screen, and as you consider larger screen sizes, you can show more content. Which brings us to…
Responsive Design
Responsive design is about making a site provide the information the user is looking for regardless of the screen size.
So using CSS, we can code the site to show the the information we think the user is looking for, and at specific screen sizes, the CSS changes to show or expand more pieces of the website.
Exercise: choose a website and check to see if it’s responsive by changing the size of the browser window.
Library-related Responsive Design Resources:
“Special” Considerations
When trying to make a website usable for everyone, there are a few considerations, which I label “special” because many people are not aware of or don’t think about these issues.
Colour Contrast
The first one I’ll touch on is colour contrast. Have you ever tried to read black text on a grey background? A higher background and text contrast helps not only those who are colour blind or have low vision, it also helps in extreme lighting environments. Ever try to read something on your phone with the sun shining on it? Well you’re more likely to be successful when you’re looking at something with a high contrast.
We’ll come back to this again later, so we’ll move on for now.
Keyboard Accessibility
Every element that a user can interact with should be accessible using only a keyboard and also visually show the user what they are focused on; namely links and form inputs, including search bars.
Exercise: Try using the tab key on your keyboard to move from one interactive element to another. You can usually tell if you’re moving from one link to another by the display in the bottom left corner that shows the address of where a link goes. As you tab through, can you see what you’re focused on? Do you get stuck anywhere? What about if you click inside the search? Is there anything to indicate focus?
Forms
Additionally, forms should have labels, even if they are visually hidden.
Forms can get complex, so if you’re interested, you can read up on form best practices and accessibility at Form Elements and Accessibility.
Skip Links
You might have noticed that when I was tabbing through, you saw links pop up in the top left corner. The ones that you saw are what are called “skip links”. These are links that you can’t normally see, which allows users to skip the parts of the website the repeat from page to page, namely from the top of the page to the menu, and then from the menu to the content.
Media
Anytime you have some kind of media, whether that be images, audio, or video, you should have a text-based alternative.
With images, you would use alternative text or “alt text”. When the image is purely decorative, or the message is already in text format, you don’t actually need it. There are lots of articles, and flow charts that will help you determine when you need it and when you don’t.
With audio and video, you will want to have captions, or a transcript. You also want to make sure that your audio and video do not automatically play.
Another exercise: Does anyone notice anything wrong on this site? Does anything autoplay on this site?
Usually called carousels or image sliders, they are rampant on websites.
From the list of top 10 academic websites
- 6/10 have carousels
- 5/6 autoplay
Taking the top 10 from the 20 Great Public Library Websites list
- 9/10 have carousels
- 9/9 autoplay
I won’t say every, but almost all carousels are inaccessible and can really be a problem accessibility-wise. If you want more reasons not to use a carousel, check out Should I Use a Carousel.com
Documents
I just want to briefly touch on documents, because they’re so prevalent.
If you ever need to create or edit documents, simply follow best practices and you should be fine. If you’re making a PDF, create it from your document and you should be fine on that front too.
Microsoft Word and PowerPoint, as well as Adobe Acrobat, do have accessibility checkers built-in that can help you as well.
Testing and Assessment
At the very basic of website testing is making sure it works across browsers and platforms. More specific to accessibility, you can use automated methods or tools.
Tools
Just a few examples:
- 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,
- Fangs, a Firefox plugin, which emulates a screen reader by providing what would be read in text form
- VisCheck which processes images to simulate colour blindness (Vischeck also provides a tool called Daltonize, which attempts to correct images)
- Colorblind Web Page Filter
Exercise: go to colorfilter. If there are lots of images, it might take a little bit of time and the layout may not look exactly the same, but this should give you an idea of what it’s like for someone with that particular type of colourblindness you’ve chosen.
Developer toolbars, semantic markup and automated testing tools can only get you about 30% of the way towards Web Accessibility goals. – Denis Boudreau @dboudreau & Matt Feldman @hlpsom1
The key is to
ask your users
whether fictional (as may be the case with user persona) or real.
If you can’t find users, since JAWS and some other accessibility software can be quite specialized, sometimes requiring special training, ask others for help. If you work in an academic library, go to the disability services department. If not, there are also organizations, such as VIRN, who can help.
Training and Documentation
A big part of getting buy-in is to get other people involved. You want to make accessibility part of everyone’s job. Change their mindset by making them accountable.
A common trend is that library staff are using web-based systems to create and maintain content relevant to their areas in the organization. For example, someone in collections will write and update the collections policy. The content they write affects users, so making sure the content is accessible is part of their job.
We need to make simple, readable, effective content. – Anne Gibson
Other than to write clearly and concisely (because our users don’t want to read whole paragraphs to get the answer they want), I provide these points to keep in mind:
- 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
- Use tables for data, not layout.
- Describe 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
That’s it. Five simple guidelines.
Other Examples:
- LibGuides Presentation: Accessibility by Adina Mulliken
- Facilitating Accessible Instruction and Resources (University of Victoria)
- United Nations Accessibility Guidelines: Content
General Resources
- WCAG Quick Reference
- The Paciello Group Blog – a lot of great articles on focused on accessibility and HTML/CSS
- The Accessibility Project – lots of quick tips
- Canadian Guidelines on Library and Information Services for People with Disabilities (out of date, currently being revised) by CLA
- Accessibility Information Toolkit for Libraries by OCUL
Lists of Accessibility Resources:
- Accessible Technology: Tools & resources by the University of Washington
- Tools and Resources for Accessible Web Design by Texas School for the Blind and Visually Impaired out of date but still a number of useful resources
- Code4LibBC Accessibility Breakout Group Notes
I’ve included additional resources, but this is by no means an exhaustive list.
Take Away
A colleague and friend asked me recently,
What are the 1-3 things you wish everyone in web tech knew and/or could do about accessibility? – @ThatAndromeda
My only answer is to keep your users in mind, all of them. If you do nothing else, even if you’ve already forgotten everything else I’ve said, follow those 5 simple guidelines I presented when writing web content, because every little bit helps.
Websites are software that help people accomplish their goals, regardless of the hardware and software combination, regardless of the shapes and forms of their people. That is accessibility. – Anne Gibson