If you’ve read my previous posts on web accessibility, then most of this will be a rehash. This is the version that I did for the TRY 2013 conference, where I reorganized a few things and put in different examples.
Slides
I’m not going cover everything, but do my best to give you an overview of the various issues and how to put web accessibility into practice.
Definition
Most seem to define web accessibility to mean making the web accessible to those with disabilities (W3C Web Accessibility Initiative (WAI)’s definition).
Do you know the different types? Auditory, visual, motor, and cognitive.
I prefer the more general meaning, of making the web accessible equally to everyone, including those with disabilities Wikipedia’s definition. That is, regardless of whether someone has a disability, they should be able to access information in their preferred manner including using any browser, operating system, or device.
Why Should You Care?
Legislation and regulations exist in many areas stating that public institutions must adhere to a set of web accessibility guidelines.
Even if it’s not legislated, many institutions (public and private) will have policies or mandates on being inclusive that require or promote equal or equivalent access to all users.
While web accessibility generally focuses on providing and improving access for persons with disabilities, making sure your site follow a set of guidelines can also improve the experience of your other users as well.
What is WCAG?
The Web Content Accessibility Guidelines are just that, a set of guidelines, written by the Web Accessibility Initiative (WAI) group of the W3C, separated into 3 levels: A, AA, and AAA.
AODA Deadline
In Ontario, we have the Accessibility for Ontarians with Disabilities Act (AODA), which states that all public institutions must conform to the Web Content Accessibility Guidelines (WCAG) by next year.
Guiding Principles
Perceivable
- Provide alternatives for non-text content, or for content to be presented in different ways.
- Make it easy to see and/or hear content.
Operable
Understandable
Robust
Understanding WCAG
To wade through the specifics, I suggest using the quick reference, How to Meet WCAG 2.0, and use the customization based on your current technologies and focus.
One of the criticisms of WCAG is that the documentation can be difficult to understand and follow. Rather than focusing on the guidelines themselves, I’ve structured the presentation around best practices and general web design principles while noting which guideline is covered.
In my own experience, some of the techniques that they suggest to meet a particular guideline recommend the use of code that is obsolete. For example, under Sufficient Techniques for 1.3.1, Technique H73 tells you to use the summary attribute in table elements to provide an overview of what a given table is about. However, the summary attribute in HTML5 is deprecated.
So while the techniques can provide some good suggestions, this issue is another reason I prefer to focus on following general web design principles and practices.
Template
Let’s start with the big picture.
Whether your site is developed in-house or not, I hope you’re using a template, otherwise you might be making your website inaccessible for everyone, not just those with disabilities.
It might seem obvious, but a template will help you with:
- consistent navigation (3.2.3)
- consistent identification of the different parts of each page (3.2.4) – i.e. you assign ids consistently
- providing multiple ways to discover content (2.4.5) e.g. links, search, site index
- meaningful order to content (1.3.2, 2.4.3) – this particularly refers to the order something is read by a screen reader and tabbed through using a keyboard i.e. secondary content after primary; the easiest way to ensure that the order is correct is to make sure the code is in that order – obviously applies to website as whole
- presentation and layout should be separate from content. So layout control (such as sizes, floats, padding, etc.), colours, fonts, and practically anything you would put in ‘style’ should be done in CSS, separating it from the HTML (1.3.1)
- avoiding (i.e. do not use) tables for layout purposes
Device Accessibility
While not a specific requirement of WCAG, I would be remiss if I didn’t briefly talk about device accessibility. Just from laptop to desktop, the screen sizes can vary a great deal, let alone when we get into mobile devices. With responsive design, a website will change itself depending on the size of your screen from desktop to tablet to mobile.
This should also help since one of the guidelines is to make sure a website can be zoomed in at 200% without any problems.
I know that a team from UofT will be presenting today as well on the process of making the catalogue responsive, so I encourage you to attend if you’re interested in learning more.
Structure
Next, let’s move to the anatomy or structure of the website.
I feel like structural points are also really obvious, so I’m just going to go through them fairly quickly.
- valid markup (4.1.1) – such as the w3c validator
- page title (2.4.2) – every page needs to have a page title using the title tag in the head
- every page should also specify what language it’s in, such as English or French
- Bypass Blocks (2.4.1): You can allow bypass blocks by inserting an in-page link that would allow users to skip blocks of content that are repeated on the various pages of a website. For example, you might have a link at the very top of the page to skip to the main menu (global nav) or the content. At the main menu, you again might have something similar.
ARIA Roles
I’ve going to digress here, because especially with all the new HTML5 elements, the idea is that assistive technology can determine the purpose or role of various sections of a webpage without further coding needed. Great right?
Unfortunately, while HTML5 support increases with every release, HTML5 accessibility support varies by browser and assistive technology software. To help your users using assistive technology in the meantime (that is, until HTML5 is fully supported), it is recommended to use ARIA (Accessible Rich Internet Applications) roles. These are normally only used for custom aspects, particularly interactive pieces, but help during this transition period.
The problem of course is that unless you’re already familiar with the topic, you might never have even heard of ARIA, let alone understand how you would apply them. Honestly, you’re not alone. There just isn’t a lot of documentation out there (at least that I have found), but a working draft on Using ARIA in HTML has been fairly recently created. The recommendations table lays it out simply for you which ARIA roles should be defined based on current overall browser support.
A simple way to think about it is that a role tells the user the purpose of the element or the content in the element. For example, the purpose of ‘nav’ is providing ‘navigation’, or the purpose of ‘footer’ is to provide information about the webpage, such as copyright or privacy statements.
If you put it all together, the structure of a page might look something like this:
This applies to other elements as well.
Presentation
One of the key issues with presentation is colour contrast, which needs to be at least 4.5:1, except logos and large text (18+pt, 14+pt bold), which require a minimum 3:1 ratio
But how do you calculate the contrast ratio of colours? There are formulas for you to use to calculate it, but honestly, it’s a lot easier to just use a tool to do it for you.
I personally use Contrast Check, a Firefox plugin, which will check whichever web page you have open. Just be cautious that it’s checking the right colours.
Textual Content
So now, let’s get into the meat of things. For the most part, those who create the content on the website are not the same people who create templates and maintain the system. So the rest of the presentation will focus on guidelines that deal with the content. We’ll start with the easy stuff and work our way up.
Headers
Imagine you’re writing a report. Think about how you would structure the headings. You’d have your title as a header 1, your various topics as header 2, and any subtopics as header 3. You might even have header 4, 5 or 6 depending on how much you break down each topic. Now apply that thinking to how you structure content on a web page.
The problem that usually occurs is when different headers or simply bold are used for the look rather than what it means structurally.
Links
The text for every link should be descriptive (2.4.4) and unique (within a single page). Imagine there was no other text around it (except the title of the page), would you understand what that link is for? If you can’t do it yourself, don’t expect your patrons to.
Text in a Foreign Language
Similar to how your page should say what language it’s in, chunks of text (e.g. quotes, titles) in another language should be marked (3.1.2) with the ‘lang’ attribute in the same way.
Tables
Back in the day, one of the few ways to lay out your content was to use tables, but nowadays, tables should only be used for information and data that should be presented in a tabular format (1.3.1).
Forms
Some accessibility guidelines are fairly specific to forms. While most people think of full fledged forms, such as tax forms, or something simpler like comment forms. Form guidelines actually apply to any time there is input with even a single input box, such as a search bar.
On Focus & Input Behaviour
Whenever an element can take input or interaction from the user, the current focus should be visible (2.4.7). The most basic example is the border/shadow effect when your cursor is in a text box.
Putting focus on or entering something into an element should also not change the context (3.2.1, 3.2.2). Finally, submission should be manual.
Avoiding and Correcting Mistakes
Appropriate labels (and possibly instructions) should always go along with user input (3.3.2). Form elements in particular should generally each have a label element attached.
Any errors in input should always be identified and described (3.3.1), with corrections suggested whenever possible (3.3.3). For business transactions, particularly related financial or legal transactions, all data should be given to the user to be reviewed first (3.3.4).
Media
Let’s get into the stuff that tends to added colour to your site.
Images
Alternate Text
When you include image elements on your website, you also need to include alternate or alt text, which allows you to include descriptive information about the image. While the text is not visible to most users, assistive technologies will read the alternate text as a description of the image, so write concisely, while still providing an accurate description of the image.
However, if your image has been included for purely decorative purposes, leave the alternate text empty. Assistive technology will ignore the image completely.
Title for Images
The title attribute allows you to provide additional information about an image in addition to the alternate text (meaning the title should not repeat alternate text). The title will also typically appear if users hover over an image with a title. However, the title is typically not seen or read, so the use of title is discouraged.
Use Text Whenever Possible
Basically, don’t use an image of text instead of just text – use CSS instead (1.4.5). The one exception is for logos.
Audio/Video, Animations & Interactions
Autoplay
In general, audio, video, animation, or anything similar should not play automatically. Instead, users should be able to hit a play button when they are ready for the content. Anything that starts automatically should have an accessible mechanism to pause, stop, or hide it (2.2.2). Some specific rules apply as well.
Audio that autoplays for more than 3 seconds must have a pause/stop control or independent volume control (1.4.2).
Nothing on the website should blink or flash more than 3 times within 1 second so as not to cause seizures (2.3.1).
Timing
Timing issues are particularly important in media and interactive elements, although it applies to any session based activity, such as bookings and forms. The basic idea is that anything that is on a timer can be extended and in some cases, users have to be warned (2.2.1).
The exceptions are when it’s in real time (e.g. auction) or it’s essential (e.g. timed quiz).
Alternatives to Media
All non-text content, including audio and visual materials should have an alternate (1.1.1), typically a text transcript and/or descriptive audio (1.2.1, 1.2.3). Much like images, if the audio/video is actually an alternate to text, such as in a tutorial where an explanation is already fully explained in text form, then no alternate is required.
Meaning through Text
In general, understanding information and instructions should not be dependent on any sensory characteristics, such as sound, colour, or shape (1.3.3, 1.4.1). Think about it as: your message should be understood in text-only mode.
Captions
All audio/video should have captions (aka subtitles) again unless the actual audio/video is an alternative to text (1.2.2).
Keyboard Accessibility
Everything should be accessible through keyboard (2.1.1). For custom stuff, consider pre-made UI packages that are accessible.
Takeaway
Following web design best practices will help to make your website accessible for all your users.
Consider writing simple, easy to follow guidelines, and prompting users double check that their content is accessible.
Assessing Web Accessibility
Other Accessibility Resources
Filed under:
Events,
Web design 
AW YISS. It’s that time, beotch! Welcome to the Steotch Fine New England Needlearts Inaugural Mystery Stitchalong.
