Five articles on using ARIA

ARIA (accessible rich internet applications), is a way of programmatically adding roles, states and values to a web control that is not part of the HTML standard controls. It is used by assistive technology to provide feedback about a non-standard control. It can also be used to give additional information such as a page section that may only be visually indicated like the banner, navigation or main page section.

These five articles look at different uses of ARIA and help explain there purpose in accessibility.

1. WAI-ARIA Overview

This is the W3C WAI official site on ARIA, where the standards are documented. It may not be the easiest thing to read but it is the most accurate.

2. How to use ARIA: An introduction

This is the first part of a series on learning to use ARIA in your rich internet applications. It covers what ARIA can be used for and why.

3. ARIA Slider, Part 1

This article explains how to use ARIA to help create an accessible slider web control. It is divided into three parts. Note, the need for attention to how the script interacts with the user has a large baring on the level of accessibility.

4. Accessible drag and drop with multiple items

This article goes over how to code an accessible drag and drop feature of a web application using ARIA to help with accessibility. Note, ARIA is only part of the solution and care is required in the way the script handles user interaction, for example it needs both keyboard and mouse controls.

5. WAI-ARIA FAQ

This is the W3C frequently asked questions on ARIA and addresses many of the common questions developers and content authors have about ARIA and its uses.

Five UK Accessibility Testing Companies

Here are five different UK based companies that all offer accessibility testing services. They all can perform a range of accessibility tests to help you improve your web services, making them more accessible to everyone.

AbilityNet

The oldest of the five, at over twenty years, formed in the 1980s and possibly the largest. They are a charity limited by guarantee and have multiple offices across England.

Userite

Part of Website Auditing Ltd, a company formed in 2000, based in London England, with a single focus on web accessibility. Has a network of user testers across a range of ages and abilities.

Test Partners Ltd

Another private limited company founded in 2001, also based in London England, with a focus on software and web testing.

Digital Accessibility Centre

A non-profit organisation and a social enterprise, formed around 2012 offering accessibility testing and employs a team of user testers using a range of different assistive technology.

AccessibilityEquals

This is the newest of the five, only formed this year 2015 and is probably the smallest. With a focus on web accessibility offering testing, training and bespoke services.

My journey into web accessibility

A little background about me and my journey into web accessibility.

Who am I?

My name is John Sexton and first started learning about the web in 1999 at a short web media course at a local college. This was my first look at HTML and basic CSS. I progressed to JavaScript and started work as a web developer at Newham NHS in 2001. I had been using screen readers since 1990 with MS Dos and then Windows from 1997. I have a degenerative eye condition called retina dystrophy, which I believe to be a little similar to RP (retina pigmintosis).

During my time at Newham NHS, I developed skills in ASP, VB Script, MS SQL, PHP, MYSQL, XML and jQuery. I developed their Intranet, various web applications for different NHS departments as well as there public facing website. I also got my first guide dog Rebel, a large German Sheppard, in 2005, who quickly became very well liked by everyone.

When I first learned about WCAG

Around the time I was tasked with producing the Newham NHS public facing website, part of the remit was NHS guidelines and web standards. This is when I first learned of WCAG. As I was already a long standing screen reader user, many of the WCAG guidelines I had been already following due to my own access needs. However, I quickly learned through attending various events that there are many more access requirements different to my own and I became an accessibility advocate.

Difficulties as a visually impaired web developer

Having a severe visual impairment has its fair share of difficulties in every day life and its no different in the work place. Many systems companies choose to use will have varying degrees of accessibility issues and often as the employee, you don’t get to say what systems get chosen. So after twelve years of service at the NHS, I was made redundant and started work for a local small web design company. After six months it was time for me to try something new and I decided to go freelance.

What am I doing now?

I am building my network of web accessibility enthusiasts and like minded developers. Sharing my experiences of web accessibility and beta testing WordPress to help with the future of its accessibility. Plus I am working on a community based project for the Native Instruments Traktor DJ community.

What are my interests?

Writing code, latest gadgets and digital DJ mixing and production. As after leaving college in 1991 I started mix DJing and did mobile discos up to 1999.

If you’d like to learn more, just ask in the comments.

Web listening challenge, give it a go

Take a week to browse the web in my world. See how things work when you can only listen to content.

The challenge

  1. Download this open source screen reader software NVDA and install it on your PC
  2. Take a little time to learn the below key strokes
  3. Each day for a week, switch your monitor off and attempt to browse the web, using sites you use every day
  4. Write your experiences, frustrations and things you’ve learned
  5. Share these thoughts either on your own blog, your favourite social media or send us your thoughts

Key strokes

These are commonly used key strokes in NVDA to help move around web page content. They work across popular browsers like Chrome, Firefox and Internet Explorer.

  • 1 = Next level 1 heading
  • 2 = Next level 2 heading
  • 3 = Next level 3 heading
  • 4 = Next level 4 heading
  • H = Next heading
  • G = Next graphic or image
  • T = Next table
  • L = Next list
  • K = Next link
  • E = Next edit box
  • D = next land mark
  • Tab = Next link or control

Note pressing shift plus any of the above keys will go to the previous item. IE Shift+1 = previous level 1 heading.

  • Space = activate link or control
  • Enter = Submit or activate link or control
  • Home = Start of line or current item
  • CTRL+Home = Top of page
  • End = end of line or current item
  • CTRL+End = Bottom of page
  • Cursor Down = next item
  • Cursor Up = previous item
  • Cursor Left = previous character
  • Cursor Right = next character
  • Alt+D = go to the address bar
  • Alt+Left Cursor = back a page
  • Alt+Right Cursor = Next page

There are more controls documented in NVDA’s help although the above will be enough to get started browsing.

Reason for the challenge

I want to help spread the word of web accessibility to more people, this in turn changing the way people think about how they produce websites and their content. The internet can give the best level of accessibility to the widest groups of people no matter the technology people may use. It is the only communication media that can give visual, auditory and touch sensory access.

So if you are up for a challenge and want to make the internet a better place, have a go and share your experiences.

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.

Five must reads on web accessibility

Things I learned by pretending to be blind for a week

It’s a great challenge one I face every day as a serverely visually impaired web developer. David Ball, takes a brave step into the world of darkness and finds valuable insight and experience from the challenge.

The POUR Principles: The Starting Point for Creating Accessible Blogs

Glenda gives a great introduction to the WCAG2.0 POUR principles, it’s easy to follow and well worth a read.

What ARIA does not do

Steve Faulkner gives a quick explanation of ARIA and highlights some of its limitations as well as its key purpose.

e-Assessment and Accessibility

This gives a good insight in electronic assessments and accessibility. David Sloan explores many areas of accessibility and the impact of e-assessments have. The things to consider and more.

Specification for an Accessible Lightbox

Graham Armfield talks about the different accessibility issues around the use of a visual effect known as the light box. He covers both the effect on screen reader users and mobile devices.

Spread the word of accessibility

If you like these articles, share with a friend or if you have an article on accessibility you’d like to share leave us a comment.

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?