Tag: wcag2.0

WCAG2.0 Level AA, your guide part 2

Here we will look at the WCAG2.0 Guidelines level AA. This is the second of three levels of accessibility and in the UK is considered the minimal level for all public sector organisation web services. It will help give most people a reasonable level of access although it will not neceressally give people an equal experience.

The guidelines are based on four principles POUR, see the article Get started with WCAG2.0 for an overview.

Note before you can reach WCAG2.0 Level AA you must first meet all WCAG2.0 Level A, see WCAG2.0 Level A, your guide part 1.

Perceivable

1.2.4 Captions (Live): Captions are provided for all live audio content in synchronized media. This is to offer an alternative text based content that is presented at the same time as the live audio for the benefit of those people who may not be able to hear the audio stream. This may include people with hearing impairments as well as people who may not have any audio device available.

1.2.5 Audio Description (Pre-recorded): Audio description is provided for all pre-recorded video content in synchronized media. This is where you add audio descriptions of any relevant visual content to the video media for the benefit of people who may not be able to see the visual content. Please note this will not address people who have difficulty with both visual and audio content. To address this a textual content such as full transcript will be required.

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

  • Large-scale text (18PT+ or Bold 14PT+) and images of large-scale text have a contrast ratio of at least 3:1;
  • Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Text that is part of a logo or brand name has no minimum contrast requirement.

You can use free tools like the webaim colour checker to see if your colour contrast meets the requirements.

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. This is to allow people to use the text size option of their web browser to increase the text size. It should allow text to be double it’s original size without breaking or making it difficult to read or use.

1.4.5 Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

  • The image of text can be visually customized to the user’s requirements;
  • A particular presentation of text is essential to the information being conveyed (text that is part of a logo or brand name) are considered essential.

By using textual content instead of text within images, it will allow people to adapt the text into a format that they can use. Where as text within images are not so flexible and may not be accessible to some people. Examples may include people using Braille or people with dyslexia or limited vision.

Operable

2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. This may include things like a site map, keyword search or breadcrumb. All can help people find pages within a website more easily.

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. This is about how effective the use of language is to describe the relevant topic or purpose in headings and labels. This will help people quickly identify and understand the various topics and controls available to them. Short, simple, concise and relevant are what will be most effective.

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. This is about showing people where they currently are on a page when using a keyboard or other similar control device. Unlike using a mouse, where you have a pointer to show you, without this pointer, you need other visual indication such as highlighted outlines, change of colour or similar clearly marked visible indicator.

Understandable

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. This is referring to any content that is in any other language other than the default language set for the page. So if the default language is in English but there is a short passage wrote in French, this will need to use mark-up that specifies that it’s in French. The purpose is to help assistive technology such as screen readers, Braille displays and others know the change of language from the default set at the beginning.

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. Consistency will help people become familiar more quickly and can greatly enhance the experience for people using assistive technology.

3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. If not consistent in the naming of Components across web pages, it can give confusing or conflicting information. Leading to people being frustrated, confused or simply lost.

3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. This is about helping people understand where and what mistakes they may of made. By offering support in this way, it can help people complete tasks without the need for alternative communication. It is best if the error messages are provided in text with clear indication to where the mistake was made.

3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

  1. Submissions are reversible, meaning people can request to undo the change.
  2. Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. This will give people the chance to see any mistakes and allow them to correct them before making any commitment.
  3. A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission. This is giving people the chance to look over their information and choices before making a commitment and allowing them to make any changes required.

    4. Robust

    There are no level AA or AAA guidelines in the last principle, only 2 level A guidelines.

Why infographics are not accessible

In the visual world of social media a popular content called infographics is creating accessibility barriers.

What are infographics?

These infographics are a collection of images, shapes, colours and text placed into a single image, then posted and shared across social media. There purpose is to give a quick snap shot of some content, that can be easily shared, branded and placed within blogs or other content.

Why are they not accessible?

The mixed content placed into a single image has more information than what is suitable for a simple alt text and in most cases do not have full text equivalent content placed adjacent or linked to from the infographic.

This results in people who can not see the infographic image being left in the dark. Often these images have no alt text at all. Plus because the text content is placed inside the image, people can not scale the text up or change colour or font.

What can we do to change this?

I believe the way forward is to make better use of SVG (Scalable Vector Graphics). This will both allow for clear scaling and assistive technologies can programmatically access text and other components of the image.

There is already research being done on how to make charts and diagrams more accessible through SVG2.0 and I believe the same can be done for infographics.

Conclusion

Remember that visual only content is no value to those who can not see it. The same as audio only content has no value to those who can not hear it. Text alternatives are the first guideline of WCAG2.0 Level A and not providing suitable text alternatives for infographics will break this guideline.

We are not saying to never use images or infographics it’s quite the oposit. Instead we are saying that there are always sufficient alternative text content made available to ensure they are accessible to everyone.

WCAG2.0 Level A automated checks unveiled

There are many software products that claim to check WCAG2.0 guidelines. Here we talk about which checks can be managed with software and what will need manual checks made by people. For more details about what these checks are for take a look at the previous article WCAG2.0 Level A, your guide part 1.

Perceivable

1.1.1 Non-text Content: It is possible to have software check for things like, does images within the HTML content have alt attribute and check if the value is not empty. It may even check for common mistakes like alt text that starts with "image of" or "photo of" or "picture of". It may even check for the presents of words or single character alt text like "*" or "-". However, it can’t check if the alt text relates to the image purpose or that the inline placement of the image makes sense and doesn’t cause any confusion. These checks require people to make a judgement.

1.2.1 Audio-only and Video-only (Pre-recorded): It may be possible to check if a video has an audio track, However, it isn’t possible to check for relevance or that the same information is presented in an alternative format. This will need people to check manually and may require some isolated testing of each format for comparison.

1.2.2 Captions (Pre-recorded): Again it may be possible to check if captions exist but not ensure that the captions are relevant, complete and usable. It will take people to manually check captions against the media content to ensure it’s a suitable alternative.

1.2.3 Audio Description or Media Alternative (Pre-recorded): In some cases, it may be possible to check if a separate audio description track is present but it will need people to ensure that the audio descriptions are accurate, provided clearly and in a usable timely way.

1.3.1 Info and Relationships: It is possible to check if specific HTML tags are used and if all HTML headings follow hierarchical structures. Although it can not check if the content is making best use of HTML semantics or if the text used makes sense and is relevant.

1.3.2 Meaningful Sequence: It is possible to check for the use of the tabindex attribute but it will take manual checks to see if the ordering is logical and makes sense.

1.3.3 Sensory Characteristics: It may be possible to check for commonly used phrases that may break this guideline but it will need manual checks by people to see if the guideline is actually broken or if the text instructions will make sense to all people.

1.4.1 Use of Colour: It may be possible to check the colours used or for any common colour names used in text. However, it will take people manually checking to see if colour is being used solely for identifying content.

1.4.2 Audio Control: It may be possible to check if a page has any audio start automatically and if that audio lasts longer than two seconds. However, it will take manual checks to see if the controls are accessible for everyone and any assistive technology.

Operable

2.1.1 Keyboard: It may be possible to check that if mouse events are used that keyboard or focus events are also used. However, it is not possible to automatically check that all controls can be used via a keyboard. Or that any mouse controls can equally be controlled by a keyboard without any loss of functionality or information.

2.1.2 No Keyboard Trap: It is possible to check for potential cases of keyboard traps but not check for the effects or if it will cause people any difficulties. This will take manual testing by people.

2.2.1 Timing Adjustable: It may be possible to check if any timing events are being used but it will take manual checks to measure the effects and decide if any exceptions can be made.

2.2.2 Pause, Stop, Hide: It may be possible to identify some instances of blinking or animation but it will take manual checks by people to see if they break this guideline or if any exceptions can be made.

2.3.1 Three Flashes or Below Threshold: It may be possible to check for the existence of potential high risk content but ultimately it will take people to make a judgement on how to approach the content and to manually check all media and dynamic content.

2.4.1 Bypass Blocks: It is possible to check if any internal page links exist but it takes manual checks to see if these links work effectively and serve a useful purpose.

2.4.2 Page Titled: It is possible to check if page titles exist and are not empty. However, it takes manual checks by people to ensure the titles are relevant and make sense.

2.4.3 Focus Order: This can not be automatically checked, it takes manual checks by people to see if the focus order is logical and makes sense.

2.4.4 Link Purpose (In Context): It is possible to check that links contain text, even check that duplicate link text doesn’t point to different locations. However, it takes manual checks by people to ensure that the link text used, is relevant and makes sense both in and out of context.

Understandable

3.1.1 Language of Page: It is possible to check that a page language has been specified. However, it will take people to ensure that the language set is indeed the default language for the page.

3.2.1 On Focus: It is possible to check for potential issues by finding any on focus events but it will take manual checks by people to measure the effect and see if it breaks this guideline.

3.2.2 On Input: Again it is possible to highlight potential problems but it will take manual checks by people to ensure that adequate notification is given and no unexpected action will result in confusion.

3.3.1 Error Identification: This will need manual checks by people to ensure that any errors are shown in text and that the it makes sense and is clearly indicating where the error is.

3.3.2 Labels or Instructions: It is possible to highlight missing form labels although it takes people to ensure that the instructions are suitable, clear and that all labels make sense.

Robust

4.1.1 Parsing: This can for the most part be checked by automated software, the W3C Mark-up Validation Service, is one example. However, it take people to ensure that the content is marked up with the best use of semantics.

4.1.2 Name, Role, Value: It may be possible to check for the existence of these attributes and values not being empty. However, it will take manual checks to see if the values make sense, are relevant and provide useful assistance with navigation or operation.

Conclusion

Even at this lowest level of accessibility, the kind of things that can be checked effectively with automated software is very limited. Plus if many of these checks are made during template design and content creation, it can save both time and money with checking and then having to re-engineer or change content after it’s already been published.

Remember for each level up with WCAG2.0 guidelines, you first must meet all of the previous WCAG2.0 level. So to be WCAG2.0 Level AA, you first must meet all WCAG2.0 Level A and then all WCAG2.0 Level AA checks.

Share the love

If you found this article useful, please share and send it to a friend

WCAG2.0 Level A, your guide part 1

Here we will look at the WCAG2.0 Guidelines level A. This is the most basic level of accessibility and without it, will prevent many people from being able to use your website. It may also impact the level of usability for everyone not just people who may have an impairment.

The guidelines are based on four principles POUR, see the article Get started with WCAG2.0 for an overview.

Perceivable

1.1 Text Alternatives

1.1.1 Non-text Content: Any of your web pages content that is not in regular text, such as images, video, sound, Flash or other similar content that is available to your visitors, must have a text alternative that gives an equivalent purpose, except in the cases listed below.

Regular text is any text that can be selected and understood by other technologies, such as text editors. It does not include text that is embedded into images, videos or spoken within audio. A simple test is to see if you can highlight the text and copy it into a text editor like notepad.

  • For web controls such as buttons or forms you give them text names or text labels that will explain their purpose, see WCAG2.0 4.1 for more details.
  • For time based media, the text alternative should at least give a description of the media, see WCAG2.0 1.2 for more details.
  • When providing a test or exercise in a text format would be invalidated you should at least give a description of the non text content.
  • When the primary purpose is for creating a specific sensory experience, you should at least give a description of the content.
  • When using CAPTCHAs, you should at least give a description that identifies and explains the purpose of the CAPTCHA. You should also provide alternative CAPTCHAs for different types of sensory perception. These may include, visual, audible or touch, see the article Captcha should it stay or should it go.
  • For cases when using visual effect for pure decoration or only for visual formatting, or is not to be shown to people, you should use a method that is not visible to assistive technology. Things like placing decorational images as CSS backgrounds instead of HTML image content.

1.2 Time-based Media

these guidelines do not apply when the audio or video is used as an alternative for text content and is clearly labelled as such. There is more information at WCAG2.0 Understanding Guideline 1.2.

It is worth noting that these guidelines address people with either hearing or visual impairment but do not address accessibility issues for people with both hearing and visual impairments or may not address people with cognitive impairments. Remember any time based media may effect people’s access especially for those who take more time to access and understand the content.

1.2.1 Audio-only and Video-only (Pre-recorded): An alternative for time-based media is available that gives the same information for pre-recorded audio-only content and Either an alternative for time-based media or an audio track is available that gives the same information for pre-recorded video-only content.

1.2.2 Captions (Pre-recorded): Captions are available for all pre-recorded audio content in synchronized media,.

1.2.3 Audio Description or Media Alternative (Pre-recorded): An alternative for time-based media or audio description of the pre-recorded video content is available for synchronized media.

1.3 Adaptable

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This refers to things like HTML semantics, for an example see the article Get started with Structured Headings.

1.3.2 Meaningful Sequence: When the order in which content is given affects its meaning, a correct reading sequence can be programmatically determined. This refers to things like the tab ordering and the HTML order of content as appose to any visual layout being used. It is there to help ensure assistive technology can follow the order of information as it is intended without out loosing any meaning.

1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. This is to allow people to follow instructions regardless of which Sensory control they are using such as audio, visual or touch.

1.4 Distinguishable

1.4.1 Use of Colour: Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Operable

2.1 Keyboard Accessible

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. For example if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. You are not advised to avoid other input methods like mouse or touch screens but instead allow for both. See the article A Little Accessibility Guide to Device Independence.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, like the escape key, the user is advised of the method for moving focus away. Common examples of keyboard traps are embedded objects like Flash or JavaScript that takes control over the keyboard input.

2.2 Enough Time

2.2.1 Timing Adjustable: This helps ensure that people can complete tasks without unexpected changes in content or context that are a result of a time limit. You should not use time limits on content unless one of the following applies:

  • People are able to turn off the time limit before it starts.
  • People are able to adjust the time limit over a wide range that is at least ten times the length of the default setting and before it starts.
  • People are warned before the time limit expires and are given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and they are able to extend the time limit at least ten times.
  • The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible.
  • The time limit is essential and extending it would invalidate the activity.
  • The time limit is longer than 20 hours.

2.2.2 Pause, Stop, Hide: For any moving, blinking or scrolling information that starts automatically, or lasts more than five seconds, and is not the only content available, there needs to be a way for people to pause, stop, or hide it unless it’s part of an activity where it is essential. For any auto-updating information that starts automatically and is not the only content available, there needs to be a way for people to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Content that is updated periodically by software or that is streamed to the browser is not required to keep or give information that is generated or received between the pause and resume action as this may not be technically possible, and in many cases could be misleading to do so.

An animation that occurs as part of a preload phase or similar case can be treated as essential if interaction cannot occur during that phase for all people and if not indicating progress could confuse people or cause them to think that content was frozen or broken.

2.3 Seizures

2.3.1 Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. This is to prevent people susceptible to photo-sensory related Seizures from having attacks provoked by your content. This will include animations, video or interactive content.

If you have any content that may not comply with this guideline, it is important that you make people aware before the content is shown and allow people to choose weather to proceed with the content.

2.4 Navigable

2.4.1 Bypass Blocks: Give people a way to bypass blocks of content that are repeated on multiple Web pages. This refers to things like skip links and is there to help people get to content more easily.

2.4.2 Page Titled: Web pages have titles that describe topic or purpose. This is both a SEO (Search Engine Optimisation) and accessibility requirement. The more relevant and concise the title the better. It should reflect the topic and purpose of the page and not the website in general.

2.4.3 Focus Order: This refers to the order in which items that can have focus like links, form fields, buttons and any control that people can interact with are placed. It is important that this order makes sense to people regardless of the device or assistive technology they may be using.

2.4.4 Link Purpose (In Context): The purpose of each link can make sense from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be confusing to people in general.

Understandable

3.1 Readable

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. This refers to adding a base language to the page that can be used by assistive technology and web browsers.

3.2 Predictable

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. This is to prevent any unexpected behaviour when people are moving focus from one place to another, This includes tabbing or clicking into a text field. You can read more on WCAG2.0 Understanding on focus.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. This is about always informing people of any unpredictable changes, things like a link opens in a new window. As this is not the default action of a link and may cause confusion. For more information see WCAG2.0 Understanding on input.

3.3 Input Assistance

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. When identifying errors with information entered by people, it is important to do this with text and not through images, colours or sound alone. This is to ensure it is available to everyone regardless of technology used.

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. This is for things like web forms, search boxes or login screens. Anywhere people need to enter information, suitable instructions and labels should be given.

Robust

4.1 Compatible

This is about following code standards and best coding practices to ensure the code will work equally well across multiple browsers and with various assistive technologies. You can see more about device independence and assistive technologies in the article A Little Accessibility Guide to Device Independence.

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

This is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this guideline when used according to specification.

Conclusion

For WCAG2.0 Level A, the first and lowest level of accessibility guidelines, it has 25 different things to check. These are across all four POUR Principles and broken into guideline categories like 1.1 Text Alternatives.

You can appreciate after reading through these initial guidelines, that knowing a little about assistive technology and how people use these technologies, why the guidelines exist.

My next post will go over each of these 25 checks and explain why I believe they may or may not be tested with automated systems.

Don’t miss another accessibility article!

Enter your email below and get free updates as soon as they become available.


We respect your privacy and do not spam.

Accessibility with Braille display technology

U2Mini Braille Notetaker

Ever seen one of these? It’s an internet ready refreshable Braille note taker. Yes, a web browser in a portable Braille display.

Is your website truly cross platform?

You may of worked hard to ensure your site works across different screen sizes, from mobiles to large HD displays. Tested it works in all the latest browsers from Safari, Chrome, Firefox, Opera and Internet Explorer. This is all great but what about Braille devices?

What are and who uses Braille displays?

A Braille display or note taker like the U2Mini, are an electronic device that uses a matrix of pins that pop up in different patterns to create the tactile writing called Braille. Invented over two hundred years ago by Louis Braille in France. This is generally associated with the blind but is a life line to people with both sight and hearing loss. Devices like the U2Mini can be used independently and often have WIFI, Bluetooth connectivity with internet browsing built-in.

These devices generally don’t have any mouse pointer so interact with websites in much the same way as screen reader software does, via the keyboard. The other key point, is the display is only made up of a limited number of Braille characters all on a single line. The user will need to scroll through the information, only being able to read one small section at a time. A little like screen magnification software. Plus there are no indications of colour in Braille, so any reference to colours can not be used in Braille.

You may notice, the keyboard is not a conventional querty keyboard but instead a Braille keyboard. The device will manage the interfacing between the Braille keys and the expected ASCII keyboard input on your website. So you don’t need to know how to read or write Braille to support these devices.

How can we test for Braille devices

Don’t worry, you won’t need to rush out to buy one of these, for most it would be a very costly waste of time, especially if you don’t read and write in Braille.

However, there are things you can do, like follow best practice for device independence and progressive enhancement, don’t rely on colour alone to identify something and ensure you have suitable alternative text for non text items. Many of the WCAG2.0 POUR principles will still apply, so understanding these can only help you produce accessible web content.

If you want to go the extra mile you can always ask people who use Braille displays to give feedback on their experiences. There are many user groups and specialist accessibility auditors who use teams of people to perform user testing with all kinds of devices.

Have your say

  • Ever wonder how people with sight and hearing loss can get equality through the internet?
  • Ever wonder how blind people can communicate with deaf people?
  • Ever seen a Braille display in use?

Accessibility Testing, the how, what and why

It is still a bit of a minefield when it comes to accessibility testing, how do we ensure good value and that we are getting the right advice and support?

Types of accessibility testing

This generally falls into three categories, automated tests, manual tests and user tests.

Automated accessibility tests

These are computer based tests that can scan your web pages a little like the way search engines scan pages. These start from free online tests to corporate software systems costing thousands a year. They can not do a full WCAG2.0 test at a level that will ensure an accessible and usable experience for everyone. They can have a benefit over manual tests in that they are faster and less susceptible to human error. However, automated systems can be tricked and depending on the level and complexity of the test, may give false results.

Manual accessibility testing

These require a methodical approach and a high level of technical knowledge from the tester and can take considerable time for large and complex websites. They do have the advantage over automated testing in that it is harder to full a human test compared to computer tests. They are most cost effective when used on new website designs or for new features of existing sites. As it can reduce the need for re-working or re-building entire sections of code and infostructure. However, it is susceptible to human error and may include individual opinions.

User accessibility testing

This type of testing can give you the most valuable information regarding user experience but will depend on the way testing is managed and monitored. For best results it will need to take into account the nature of your website service, the target audience and a number of people testing with different assistive technology.

How often should accessibility testing be done

This will depend on factors like: how often is your site content updated, how many people manage content, the type of content used and what process you have in place for supporting your website visitors. It will also rely on the accessibility awareness of the people producing your web content.

It should be checked at least once a year for relatively static sites and at least quarterly for more frequent updates. For sites with daily updates and frequent new feature updates, it should be incorporated into your project flow as part of the QA (quality assurance) process.

What value is there in accessibility testing conformance badges

Personally I feel there is little to no value a part from showing what accessibility testing service you use and perhaps to indicate that you may have an accessibility budget. They only verify that you had a specific accessibility testing process carried out by a particular provider at a given time. It does not prove anything, as you may of broke accessibility guidelines the day after having the badge awarded.

However, if it is a recognised or required badge within your specific organisation, then it may have some credence. The W3C WCAG badges are self awarded and again give no proof of accessibility testing ever been done.

Can I do accessibility testing myself

Yes, although the level of accessibility and quality of testing results will greatly depend on your personal knowledge and experience across all areas of accessibility. This will be particularly limited in the area of assistive technology as this is a vast specialist area and very difficult to emulate different accessibility requirements.

However, there are a few things you can do to help you gain some empathy with a few areas of accessibility. Things like unplug your mouse and just use the keyboard, install a screen reader like NVDA and take a little time to learn the controls before unplugging or switching off your monitor and just working with the screen reader, you can also unplug or switch off your speakers. The kind of things are very difficult to emulate include dyslexia, Braille displays, voice activation, specialist keyboard/pointer devices and cognitive related issues.

Conclusion

Accessibility testing is a specialist part of UCD (User Centric Design) that forms the bases for any good UX (User Experience) or UI (User Interface). It is about striking a balance between many different situations and people to give the best possible experience for everyone and should be a part of your web management process. It is not a one off process that you can just tick a box and forget, it is a on going journey just like marketing or customer relations.

Alt Text, your quick guide

Alt text is short for alternative text and is a requirement of WCAG2.0 level A, for all web image content. The most basic level of accessibility and probably one of the most missunderstood issues.

Alt text, the what and why

In HTML, you can include images to be displayed in your web pages. This is done through the tag <img>. If you are using a CMS or other web content editor, you may only know it as uploading an image. Inside this <img> tag, you can add an alt text value. It doesn’t do anything visually in most browsers except older versions of Internet Explorer, which shows this alt text value when you hover the mouse over the image.

The single purpose of this alt text is to provide a short text alternative to the image for cases when the image can not be seen. This may be for a number of reasons from the browser doesn’t support images, the image failed to load or the person viewing it is not able to see due to sight impairment.

What text do we use

The first thing to note, is the purpose of the image. If the image is used as a link to something and there is no link text being used, then the purpose is to link to something.

So for instants, if we have an image of a satellite dish that is used to link to Sky TV, the alt text should say "Sky TV" and not "Satellite Dish". This is because the text Satellite Dish, does not tell you anything about the purpose of the image where as Sky TV tells you what to expect if you follow this link.

Embedded text, this is text saved inside the image that can not be selected or copied into a text editor. If your image contains embedded text then this should be included in the alt text. Unless the text in the image is too long or not relevant. So if you have a button image with the text "sign in" inside it, then your alt text should say "sign in" and not "login" or "button". This can avoid confusion when people refer to what they see when talking with people who are not able to see the image and rely on the alt text.

Generally you should avoid using embedded text, where possible and especially for long pieces of text. As it does not scale as well as regular text and alt text is only for short alternative descriptions.

Photos and other images that are used to give some general impression but does not add substantial content. These may include a picturesque photo of a location, groups of people or other atmospheric picture. They do not need every detail documented in the alt text. You can simply use a very brief text like "a picturesque view of …" or "friends gathered at …" etc.

Charts, diagrams and other complex data related images, are probably the most difficult as the alt text only needs to be a general comment to say what the chart or diagram is for, say "pie chart showing …" or "flow chart of …" etc. However, as it will also contain substantial content within the image, you should either place this information adjacent to the image in a text form or have a link to a text alternative that says something like "details of the pie chart on …" or "detailed description of the flow chart on …".

HTML does support something known as longdesc, short for long description. However, it is often used incorrectly and not well supported or understood. So either of the other methods are generally preferred. To find out more about using HTML longdesc, see www.w3.org/TR/WCAG20-TECHS/H45.html.

There was some controversy over longdesc in HTML5, you can read a little about this on Bruce Lawson’s longdesc in HTML5 article.

Decorational images, these are images that add no content value to the page and are only there for visual decoration. These may include things like background textures, ribbons, floral borders etc. The best practice is to separate these into your style sheet and not include them within your HTML content. Many people have tried different methods from using null or empty alt text to generic non descriptive alt text like an asterisk “*” or words like “spacer”.

The problem is if you place decorational images inside your HTML, it is treated as content and not just styling. So people who use assistive technology like a screen reader, may be able to detect the image but either get no text or text with no meaning. This can cause people to believe they are missing out on content or just have a distraction to other content.

Tips for alt text

  • Don’t start with things like "image of …" or "Picture of …" or "Link to …" as assistive technology will already be able to indicate this and it results in people being told twice it is an image before they find out its real purpose.
  • Keep the alt text short, meaningful and relevant to its purpose.
  • Place text alternatives for complex charts, diagrams or other data content adjacent to the image or in a separate page linked to from either the image or adjacent text link.
  • Think carefully before choosing to use the HTML longdesc and remember it is to link to the long description and not contain the long description itself.
  • Place decorational images in your style sheets, to keep your content and styles separate.
  • Take care where you place images within your content, inline images placed in the middle of content can be both distracting and confusing, regardless of how it is displayed through your style sheet.
  • Ask people who use assistive technology, if the content including images makes sense or ask an accessibility specialist.

Conclusion

Understanding alt text is part of the first principle of WCAG2.0 Perception, How people view your content regardless of ability or any assistive technology used. It is in the lowest minimum level WCAG2.0 A and can effect many people as well as your SEO (Search Engine Optimisation).

So taking a little time to understand alt text and just spending a few extra minutes on your page content can make a difference to your SEO and the people who view your web pages.

Get started with WCAG2.0

WCAG (Web Consortium Accessibility Guidelines), were first published in late 2008. These are a revised set of guidelines from the original WCAG published guidelines and aim to address the issue of the rapid changes in technology by focusing on people instead of technology.

Were to start with WCAG2.0

The first thing to note is that they are guidelines not standards. So they are designed to help guide you and are not there to restrict you or be treated as tick boxes.

Where as W3C code standards are exactly that, standards, which should be followed to ensure future compatibility with web browsers. Failing to comply with W3C code standards is likely to result in incompatibility issues across old and new browsers a like.

Although within the UK public sector, it is a requirement that all web services meet the WCAG2.0 level AA guidelines as a minimum standard. This is a good level to aim for and is achievable, However, it may not address all accessibility issues that people may face.

Principles used in WCAG2.0

The WCAG2.0 guidelines use four principles, known as POUR (Perceivable, Operable, Understandable and Robust). Lets take a look at each of these in turn.

WCAG2.0 Perceivable principle

This principle is to ensure that people of all abilities can recognise and take in all the information given on your web page. Plus be able to make out the various sections and controls that they can use. So this will include the way you structure your content, the kind of controls you use as well as the colour and design.

WCAG2.0 operable principle

This principle is about how people use and interact with your website. People must be able to operate all controls on your web page, regardless of what device or assistive technology they may use. So this will include areas of device independence and an appreciation of assistive technology and the different ways people may interact with your website.

In today’s vast range of web enabled devices, it will include everything from touch screens, voice control, Braille or other specialised keyboard as well as your regular keyboard and mouse.

CAG2.0 Understandable principle

This principle is about making sure that your information and the way to use your website is easy and not beyond anyone’s ability. The article Accessibility, it’s in a KIS can help you with this principle.

WCAG2.0 Robust principle

This last principle is about future proofing by ensuring your website code conforms to coding standards and that it can work with assistive technologies. This will include things like cross browser support, mobile responsiveness and again device independence. It will also include code maintenance and removal of deprecated code as well as progressive enhancement or graceful degradation.

Useful resources