Skip to main content

We write about Digital Accessibility. This includes topics related accessibility news, accessibility events, accessibility techniques, reviews of websites and applications, tips related to accessibility and in simple words all possible things about digital accessibility.

Tagged as

WCAG 2.1

New Success Criterion in WCAG 2.1: 2.5.1 Pointer Gestures (Level A)

Success Criterion 2.5.1: 2.5.1 Pointer Gestures (Level A): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

With increase in touch devices, method of pointer gestures have become quite common. It has also become popular when users can use diverse range of gestures. 

Let’s take an example of a news app; by use of pinch, user can zoom in and zoom out the text. However, when user does not have ability to pinch, there should be alternate method of achieving the same functionality. Perhaps by using Zoom-in and Zoom-out buttons or with an option in app settings. 

That said, this success criterion does not to apply to functionality provided for the operating systems – such as swiping down to bring notification menu or functionality provided in assistive technologies; such as talk back (screen reader on Android) has its own gestures for ease of use. 

Another exception is where path based gesture is a mandatory such as drawing a signature. 

How to test?

Identify if a functionality requires use of path based gesture such as swiping, dragging or drawing. One of the examples would be “Place an order” element on Amazon app where user requires to swipe from left to right to complete the order. Another example would be zoom-in or zoom-out on maps. 

Web Content Accessibility Guidelines (WCAG) 2.1 is now official

On 5th June, 2018 Web Accessibilty Initiative of World Wide Web Consortium has announced that Web Content Accessibility Guidelines (WCAG) 2.1 has become official recommendation as standard. There has been tremendous efforts by Accessibility Guidelines Working Group which includes task forces for Cognitive, Low Vision and Mobile users. This is an evolution of W3C’s accessibility guidance, including expansion of mobile, low vision, and cognitive and learning provisions. It maintains W3C’s accessibility guidance, while maintaining W3C’s standard of implementable, technology neutral, objectively testable and universally applicable accessibility guidance.

New Support in WCAG 2.1

For users of mobile devices, WCAG 2.1 provides updated guidance including support for user interactions using touch, handling more complex gestures, and for avoiding unintended activation of an interface. For users with low vision, WCAG 2.1 extends contrast requirements to graphics, and introduces new requirements for text and layout customization to support better visual perception of web content and controls. For users with cognitive, language, and learning disabilities, WCAG 2.1 improvements include a requirement to provide information about the specific purpose of input controls, as well as additional requirements to support timeouts due to inactivity. This can help many users better understand web content and how to successfully interact with it.

As with WCAG 2.0, following these guidelines will continue to make content more accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and learning disabilities and cognitive limitations. Following these guidelines can also make websites more usable for all users.

Read the complete blog post by Andrew and Micheal on W3C Blog

Here are list of New Success Criterions in WCAG 2.1

Guideline 1.3 Adaptable

Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Comic with cerebral palsy who uses a wheelchair:

  • Problem:I can’t rotate my tablet — it’s attached to my wheelchair.
  • Works well:The application works whether I attach my tablet horizontally or vertically.

Understanding Orientation

1.3.5 Identify Input Purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

Supermarket assistant with dyslexia and dyscalculia:

  • Problem:My address is so complicated. There’s lots of numbers and long words. It’s hard to type it all without making mistakes.
  • Works well:I love websites that can automatically fill it all in for me. Then I don’t have to work so hard to get the numbers and spelling right.
    Note: This works because the fields use autocomplete.

Understanding Identify Input Purpose

1.3.6 Identify Purpose (AAA)

In content implemented using markup languages, the purpose of User Interface Components, icons, and regionscan be programmatically determined.

Gamer with language processing disability:

  • Problem:I have software that changes the words in the navigation into symbols. It doesn’t work at all with some websites.
  • Works well:It works pretty good with some websites.

Understanding Identify Purpose

Guideline 1.4 Distinguishable

Make it easier for users to see and hear content including separating foreground from background.

1.4.10 Reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels;

Except for parts of the content which require two-dimensional layout for usage or meaning.

Parent with low vision – 20/400:

  • Problem:It’s nearly impossible to read text if I have to scroll right and left to read each line. It’s disorienting and I lose my place. It makes it hard to understand what I’m reading.
  • Works well:I increase the text size 400% and it reflowed within the width of the window. I can read it easily without scrolling back and forth.

Understanding Reflow

1.4.11 Non-Text Contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components
Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Retiree with low contrast sensitivity:

  • Problem:I couldn’t use the “Order Form” — there were no text boxes. After a long call with customer service, I learned there were text box borders that were too light for me to see.
  • Works well:It’s easy for me to see all the icons and buttons and everything — even in the sunlight.

Understanding Non-text Contrast

1.4.12 Text Spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Student with dyslexia:
and Retiree with low vision:

  • Problem:Most text is hard to read. It’s so cluttered I can’t keep my focus. Just increasing the space between lines makes all the difference. When I’m really tired, I also increase the space between words.
  • Works well:OK, I know I’m a bit of a geek, but I’ve perfected a user style sheet to make text spacing just right for me. It’s a relief when websites work with my CSS.

Understanding Text Spacing

1.4.13 Content on Hover or Focus (AA)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissable
mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
Hoverable
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
Persistent
The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Teacher with low vision who uses screen magnification software:

  • Problem:I was moving my mouse around to track what I was looking at on a web page. It helps me keep focused. Then -boom- this little box popped up. It covered what I was trying to read and I couldn’t get it to go away.
  • Works well:I hovered over a word and a box popped up with the definition, but it was mostly off the screen with my magnification. I moved my mouse pointer to the definition box and scrolled the magnified area over to the definition box and it stayed popped up so I could read it.

Understanding Content on Hover or Focus

Guideline 2.1 Keyboard Accessible

Make all functionality available from a keyboard.

2.1.4 Character Key Shortcuts (A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off
mechanism is available to turn the shortcut off;
Remap
A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc).
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

Reporter with repetitive stress injury who uses voice recognition software:

  • Problem:When I was using my mail app with voice commands, it kept deleting the messages instead of opening them.
    Note: There was a shortcut key for delete that was triggered by something he was saying, and no way to turn off the shortcut keys.
  • Works well:In my spreadsheet application, there’s a setting to turn off or modify character key shortcuts.

Understanding Character Key Shortcuts

Guideline 2.2 Enough Time

Provide users enough time to read and use content.

2.2.6 Timeouts (AAA)

Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.

School playground aide with cognitive disabilities:

  • Problem:I was selecting my Employee Benefits and was comparing the different plans. When I went back to select the Health Plan, it had timed out and lost all the information I had already entered.
  • Works well:When I started the Employee Benefits app, it told me how many minutes I had to complete the forms.

Understanding Timeouts

Guideline 2.3 Seizures and Physical Reactions

Do not design content in a way that is known to cause seizures or physical reactions.

2.3.3 Animation from Interactions (AAA)

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Artist with vestibular disorder:

  • Problem:In the online tax app, as I move my mouse around or tab to different fields, this little bubble with the current balance follows me around the screen. Makes me dizzy and nauseous.
  • Works well:I was so glad there was an option to turn off animations.

Understanding Animation from Interactions

Guideline 2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

2.5.1 Pointer Gestures (A)

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointerwithout a path-based gesture, unless a multipoint or path-based gesture is essential.

Comic with cerebral palsy who has limited movement in fingers:

  • Problem:I can’t move my fingers like that. I need another way to zoom in the map.
  • Works well:Good thing there are buttons to zoom in and out.

Understanding Pointer Gestures

2.5.2 Pointer Cancellation (A)

For functionality that can be operated using a single pointer, at least one of the following is true:

No Down-Event
The down-event of the pointer is not used to execute any part of the function;
Abort or Undo
Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;
Up Reversal
The up-event reverses any outcome of the preceding down-event;
Essential
Completing the function on the down-event is essential.

Politician with motor disabilities and low vision:

  • Problem:I went to hit the “Mute” button and accidentally touched the “End Call” button instead. It hung up immediately.
  • Works well:In another web conferencing application, if I accidentally touch the “End Call” button, I can just slide my finger off the “End Call” button and it won’t end the call.

Understanding Pointer Cancellation

2.5.3 Label in Name (A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Reporter with repetitive stress injury who uses voice recognition software:

  • Problem:It understood most of my voice commands until I got to the Send button. I kept saying ‘Send’ and it didn’t work.
    Note: It was visually labelled ‘send’ but the ‘name’ in the code was ‘submit’. It would have worked if the ‘name’ started with ‘send’.

Understanding Label in Name

2.5.4 Motion Actuation (A)

Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:

Supported Interface
The motion is used to operate functionality through an accessibility supported interface;
Essential
The motion is essential for the function and doing so would invalidate the activity.

Comic with cerebral palsy who uses a wheelchair:

  • Problem:I can’t shake my phone; it’s connected to my wheelchair. So there needs to be another way to activate that feature, like a button.
  • Problem:I have tremors, so I need to turn off motion activation — and then be able to do stuff without motion actuation.
  • Works well:My friend has this cool application that looks like a physical spin lock. She rotates the phone to turn to the combination. I can use the same application by typing the numbers directly.

Understanding Motion Actuation

2.5.5 Target Size (AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

Equivalent
The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
Inline
The target is in a sentence or block of text;
User Agent Control
The size of the target is determined by the user agent and is not modified by the author;
Essential
A particular presentation of the target is essential to the information being conveyed.

Retiree with hand tremor (and big fingers):

  • Problem:The buttons are so small, I hit “Cancel” when going for “Submit”. Then I have to start all over again.
  • Works well:This website buttons are big enough that I don’t hit the wrong button even when I’m riding on the bumpy bus.

Understanding Target Size

2.5.6 Concurrent Input Mechanisms (AAA)

Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.

Reporter with repetitive stress injury who uses voice recognition software:

  • Problem:When my RSI acts up, I switch back and forth a lot between keyboard, mouse, stylus, voice. This application doesn’t let me use the stylus when I have a keyboard plugged in.

Understanding Concurrent Input Mechanisms

Guideline 4.1 Compatible

Maximize compatibility with current and future user agents, including assistive technologies.

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Accountant who is blind and uses a screen reader:

  • Problem:I selected a class for the conference, but I can’t tell if it got added to my schedule.
  • Works well:When I add a meeting to my calendar, I hear a confirmation.

Understanding Status Messages

Above details are reproduced from What’s new in WCAG 2.1 on WAI Website.

ServeOM Inclusion will be happy to assist community in understanding WCAG 2.1, testing products against WCAG 2.1. Do contact us to have a conversation.

Gratitude to everyone involved in building these standards.

WCAG 2.1 is now a proposed recommendation

Web Content Accessibility Guidelines (WCAG) 2.1 has become a proposed recommendation a while ago. This is possibly a last step before a standard becomes W3C recommendation. In short, this process is to confirm if required corrections are made. Here is what it means in the words of W3C.

7.6.4 Call for Review of Proposed Corrections

Document maturity level: A Recommendation, plus a list of proposed corrections. The Working Group should also include a detailed description of how the Working Group plans to change the text of the Recommendation for each proposed correction.

Announcement: The Working Group must announce the Call for Review to other W3C groups, the public, and the Advisory Committee. This is not a formal Advisory Committee review. However, the announcement must clearly indicate that this is a proposal to make normative corrections to the Recommendation and must:

  1. specify the deadline for review comments;
  2. identify known dependencies and solicit review from all dependent Working Groups;
  3. solicit public review.

Purpose: At this step, W3C seeks confirmation of proposed corrections to a Recommendation.

Entrance criteria: The Working Group calls for review when, with respect to changes to the document, the group has fulfilled the same entrance criteria as for a Call for Review of a Proposed Recommendation.

Duration of the review: The announcement begins a review period that must last at least four weeks.

Ongoing work: Same as for a Proposed Edited Recommendation.

If there are no formal objections to the proposed corrections, W3C considers them normative. The Working Group must report formal objections to the Director, who assesses whether there is sufficient consensus to declare the proposed corrections to be normative.

So this should be final and final chance to have any say and contribute to WCAG 2.1. As I see it, there have been a lot of great efforts and WCAG 2.1 looks awesome. Why not we just start implementing it?

Gratitude to all those who have closely involved in putting these standards together.

WCAG 2.1 is now a candid recommendation

Accessibility Guidelines Working Group of W3C has published WCAG 2.1 as a candid recommendation (CR). Purpose of CR is to ensure that standard can be implemented. Results of this exercise will be made available on WCAG 2.1 Implementation report once it’s completed. Working group plans to complete this by June 2018.

What’s new in WCAG 2.1

Addresses more accessibility requirements of people with cognitive disabilities, people with low vision and improves accessibility of mobile. Features of WCAG 2.1 are:

WCAG 2.1 extends WCAG 2.0 by adding new success criteria, definitions to support them, guidelines to organize the additions, and a couple of additions to the conformance section. This additive approach helps to make it clear that sites which conform to WCAG 2.1 also conform to WCAG 2.0, thereby meeting conformance obligations that are specific to WCAG 2.0. The Accessibility Guidelines Working Group recommends that sites adopt WCAG 2.1 as their new conformance target, even if formal obligations mention WCAG 2.0, to provide improved accessibility and to anticipate future policy changes.

The following Success Criteria are new in WCAG 2.1:

Many of these success criteria reference new terms that have also been added to the glossary and form part of the normative requirements of the success criteria.

In the Conformance section, a third note about page variants has been added to Full Pages, and an option for machine-readable metadata added to Optional Components of a Conformance Claim.

What we should do

Apply WCAG 2.1 to our day-to-day work and report when a success criterion cannot be implemented. Do file an issue on Github or write to Chairs of Accessibility Guidelines Working Group.

Let’s do some exiting work! Sincere thanks to everyone involved in building accessibility standards.

Updated Web Accessibility Checklist – Operable

This is 2 of 4 in our series to put together an updated web accessibility checklist. As mentioned in our earlier post Updated Web Accessibility Checklist – Perceivable, this post may get updated once Web Content Accessibility Guidelines (WCAG) 2.1 becomes candid recommendation. (Reminder: last working draft is out; have your say soon!).

In this post, we will discuss what to check for operability of the web.

Ensure that content doesn’t flashes more than three times in one second or below the general and red flash thresholds

Level WCAG 2.1 Success Criterion What to check for?
A 2.1.1 Keyboard Ensure that functionality is operable using keyboard; including but not limited to input fields, links, buttons, menus, controls, etc.,
A 2.1.2 No keyboard trap Ensure that there is no keyboard trap. If users gets focused on an element using keyboard, they should be able to move out of the same component with the keyboard interface.
A 2.2.1 Timing Adjustable Ensure that user is alerted about session time-out and there is a mechanism to extend the session time. except where session time-out is essential such as for a test etc., In such a case, user should be notified and alerted.
A 2.2.2 Pause, stop, hide For blinking and moving content that starts automatically and plays for more than 5 seconds, provide a mechanism for user to pause, stop or hide. For auto-update of content, allow user to pause, stop, hide or change frequency of update.
A 2.2.6 Accessible Authentication Ensure that authentication process itself is accessible. This is a new SC in WCAG 2.1 – more interpretations will be available soon
AA 2.2.7 Interruptions (Minimum) Ensure there is an easy mechanism is available to postpone or suppress interruptions. Unless they are initiated by the user. This is also a new SC in WCAG 2.1
A 2.3.1 Three flashes or below thresholds
A 2.4.1 Bypass blocks Use any of the following methods to help users (specially keyboard only and screen reader) to bypass repeated blocks of content such as navigation.

  • Provide Skip to main content link. This needs to be the first link on the page. This can be visible or made visible on focus
  • Use appropriate heading structure using <heading> mark-up
  • Use ARIA landmark roles
A 2.4.2 Page titled Ensure every page has a descriptive and unique title. This should describe purpose or topic of the page
A 2.4.3 Focus order
  • Ensure tab order is meaningful for focusable elements
  • When activating an element opens a modal, ensure that keyboard focus is placed on the modal
  • When user is navigating within a modal, ensure that focus does not shift away from the modal until user closes modal
  • When user closes modal, ensure focus returns to the triggered element
A 2.4.4 Link Purpose Ensure that context of link is available with link text alone. Avoid use of link text like Read more, click here etc., if used, ensure to provide descriptive information using techniques like <aria-describedby> or using <off-screen> text.
AA 2.4.5 Multiple ways Ensure that there are more than one way to find content on the website. Some of the techniques could be use of Site search, Site map etc.,
AA 2.4.6 Headings & Labels
  • Ensure that all sections or topics have headings using <heading> attribute. This is helpful even when a form has multiple sections
  • Ensure input fields have visible labels. Placeholders are not a great way to do unless a mechanism is implemented in a way that labels are always visible even after entering data into input field. Exception is short and usual forms such as Search form, login form.
AA 2.4.7 Focus visible Ensure focus indicator is visible on all focusable elements. Do not override focus indicator using <outline:none>. If you do not like browser’s native focus indicator, be sure to code a customer focus indicator such as using <outline:dotted>
A 2.4.11 Character key shortcuts If there is a key shortcut that require use of multiple key combinations, provide a mechanism to either turn off or map with another key combination of user’s convenience. This is a new SC
A 2.4.12 Label in name When user interface component has additional text with label, that text should be presented with the accessible name.

In WCAG 2.1, Sections 2.5 Pointer accessible and 2.6 Additional sensor input are newly introduced and we will do these sections as a seperate interpretation. Stay tuned.

Last chance to comment: WCAG 2.1 last public working draft is now available

The Accessibility Guidelines Working Group of W3C has published last public working draft of WCAG 2.1 and one can send in comments no later than 12th January, 2018. This is a fantastic opportunity for those who are not full time into accessibility but want to spend their holiday / festive session in getting acquitted with something new. A quick note from Editors of WCAG 2.1

WCAG 2.1 adds new success crtiteria to expand coverage users of mobile devices, people with cognitive or learning disabilities, and people with low vision. Most success criteria are complete, but some are still under discussion. The success criteria under discussion are marked with editorial notes and pointers to the ongoing discussion. As these success criteria are finalized, they will be updated in the Editors’ Draft

Because this is the final Working Draft, we encourage you to comment on all success criteria as soon as possible, and please comment no later than 12 January 2018. If you have comments on this draft or on continuing work on open issues, we prefer that you file input as new issues in GitHub

Alternatively, you can send email to:

public-agwg-comments@w3.org

The Working Group plans to publish the Candidate Recommendation in late January 2018. The Candidate Recommendation will include the final form of success criteria currently still under discussion, though they will be marked as “at risk” due to the lack of review opportunity from this current draft.

Additional background on WCAG 2.1 is available from previous announcements:

More information about the Accessibility Guidelines Working Group is available from its home page

So here is a final chance to have your say in building standards to create inclusive web experiences!

Updated Web Accessibility Checklist – Perceivable

Back in 2010, we have published a Quick Web Accessibility Checklist that received a good response and we have also received a good feedback. It’s true that users prefer to have a quick checklist along with large documentation to achieve their accessibility mission. So we are bringing you this updated Web Accessibility Checklist reflecting success criterions of Web Content Accessibility Guidelines (WCAG) 2.1.  Please note this checklist gets updated once again when WCAG 2.1 becomes a W3C recommendation (expected to be in 2018). Also, note that all external links on this page opens in a new window. We will be publishing this as a series of 4 posts so that it will be easy for users to refer.

Level WCAG 2.1 Success Criterion What to check for?
A 1.1.1 Non-text content
  •  All active images do have appropriate alternate text
  • All informative images do have appropriate alternate text
  • All decorative images are provided with null <alt> attribute.
  • Ensure that no informative images are used as background images. All informative images need to be in foreground and have appropriate alternate text
A 1.2.1 Audio-only and video-only (prerecorded)
  • For pre-recorded audio-only content, ensure to provide a text transcript
  • For pre-recorded video only content, ensure to provide an audio track
A 1.2.2 Captions (prerecorded) Ensure that captions are provided for all audio based content except where audio description is alternative to visual content
A 1.2.3 Audio description or media alternative (prerecorded) Ensure that audio description is provided for all prerecorded video content except where video itself is alternative to audio content
AA 1.2.4 Captions (Live) Ensure that captions are provided for live video content in synchronised manner
AA 1.2.5 Audio description (prerecorded) Ensure that audio description is provided for all prerecorded video content in synchronised media
A 1.3.1 Info & relationships
  • Has the page marked-up using semantics?
  • Page must have one first level heading using <h1>
  • Is the heading structure on the page appropriate?
  • If any content appears as a list, has it marked up using <list> attribute?
  • Has form labels associated with their input fields?
  • Are radio buttons / checkboxes associated with their group label?
  • For data tables, are data cells associated with their row / column headers?
  • Is CSS used to control the layout than using <table> mark-up?
A 1.3.2 Meaningful sequence Is the reading order meaningful from its presentation?
A 1.3.3 Sensory Characteristics Ensure that no instructions are provided in way that requires use of a specific sense of users such as using shape, color, visual location, size, orientation or sound
AA 1.3.4 Purpose of control This is a new Success Criterion and needs some interpretation to understand. This talks about personalisation of controls. While icons for different purpose may have standard icons, it’s recommended that user should be able personalise it.
A 1.4.1 Use of Colour Do not use colour as a sole means of information. Example: Normally “green” is shown to indicate success and “red” to indicate failure. While showing the same in color, it is also important to show as “text”.
A 1.4.2 Audio-control
  • Check if page any audio that plays automatically for more than 3 seconds
  • If yes, ensure that there is a mechanism to pause / stop or ability to control the volume using system’s volume control
AA 1.4.3 Contrast – Minimum Ensure that there is minimum contrast ratio of 4.5:1 for regular text between foreground and background. For large text, minimum contrast ratio should be 3:1. Incidental text such as inactive controls and logotypes do not require to have minimum ratio of contrast.
AA 1.4.4 Resize Text Ensure that user should be able to zoom in content upto 200% without use of any assistive technologies. This is not applicable for captions and images of text
AA 1.4.5 Images of text Use natural text to provide information unless it’s essential to embed text to an image. Logotype is known as essential

Tips for developers: Get your website teted for accessibility – Part 2 – Operable

This is Part 2 of 4 parts on how a developer should get their website or application tested for accessibility. Objective of this series is to provide easy method of accessibility testing to developers so that they can test as they code. This is how we would achive accessibility right at the development and design stage. These tips would not only be helpful to developers but also to interaction designers who decides interaction of elements and those who develop prototypes. This Part 2 is related to Operable section of Web Content Accessibility Guidelines 2.1.

Question: How to test for keyboard accessibility?
Answer: Load the page. Press CTRL + Home (Windows), this will take focus to the top of the page. Then use tab key to move from one element to another. Use enter or space key to activate an element. One should be able to activity every element including menus, modals, buttons etc.,

Question: When I was browsing a page with keyboard, focus does not move from an element, focus just gets stuck; is there a problem with my keyboard?
Answer: Probably not, this is called keyboard trap and needs to be avoided. When a component recieves keyboard focus, there should be mechanism to move away keyboard focus from same component.

Question: What to consider when there is a time limit for a page?
Answer: Check if there is an option to turn-off timing, adjust as per user’s requirement or extend the time limit. There could exceptions such as activity at real-time, esential time limit such as a test and time limit of 20 hours and more.

Question: What to look for elements that moves, blinks or scroll?
Answer: There should be a mechanism to pause, stop or hide. If content is being updated automatically, there should be a mechanism to pause or set how periodical that an update should happen.

Question: What is bypass blocks and how do we test?
Answer: Bypass blocks is a mechanism to enable keyboard users to skip representative set of blocks such as navigation and jump quickly to main content. This can be achieved by providing “Skip to main content” link at the top, using appropriate heading structure and/or using ARIA land marks.

Question: How to test page titles?
Answer: Look at top bar of browser window and see if page title does exist and is appropriate. For example Page title should be page name along with the company / domain name. It should not be just company name only on all the pages.

Question: What all needs to be considered as Focus order issues?
Answer: Ensure that the tab order is logical, if an element opens a modal, focus focus must be set to modal and must not move out until user closes the modal, When modal is closed, focus should be returned to the triggered element.

Question: Testing for link purpose
Answer: Ensure that all links have meaningful and spell out the context to the users. Avoid links like “Read more”, “Click here” etc., Using automated tools would be effective to test this requirement.

Question: What are the multiple ways required for a website?
Answer: A search functionality or a site map. There should be more than one way to reach a specific page on the website.

Question: How to test for focus visible?
Answer: When you tab through the page, every element should receive an indicator and you should be able to see where the keyboard focus is. It can be either custom focus indicator or browser’s default focus indicator.

Tip for Developers: Get your website tested for accessibility -Part 1 Perceivable

Quite often, I receive emails from non-profit organizations asking if I can help them with accessibility testing for their newly built website. I also see most of them do not get built accessibility in mind though many of them are for organizations who offer services to people with disabilities. This post illustrate a few tips that developers can use while building a website. While we intend to see many developers have knowledge on accessibility, it’s absolutely fine to start with a willingness to build an accessible product. This post illustrates advice in the form of question and answer in reference to Web Content Accessibility Guidelines (WCAG) 2.1. This will be series of four articles to cover Perceivable, Operable, Understandable and Robust.

Question: Do you have images or any other non-text content?
Answer: When you have images, identify if they are informative images decorative images. If informative images, provide an alternate text. For decorative images, provide empty alt text i.e. alt=””; alt attribute must be present in any form of image; if not provided, path of the image gets exposed to assistive technologies such as screen reader, shown on text only browsers (or when images are turned off in the browser), shown to search engines.

Question: Do you have audio-only conent on the website?
Answer: Provide synchronized captions or text transcript

Do you have video only content?
Answer: Provide audio-description

Do you have a live audio / video event happening?
Answer: Ensure there is voice over when only visual actions are happening and captions are provided for audio. This will aid visually impaired users to know what’s visual actions are happening and hearing impaired users to know what the conversation is happening. If there is only music being played, show captions as “Music being played” and if possible what instrument is being played and some illustration.

Question: How my content should be structured and organized?
Answer: Ensure content is structured in a logical order, Headings are marked up appropriately using Hx values e.g. h1, h2 etc., Do not just decorate content as a heading, mark-up list items as ordered or unordered list, ensure all form fields do have associated labels using “for” and “id” attributes, radio buttons and check boxes have associated with their group label.

Question: My user tells me that my content is not read in right sequence, what could be wrong?
Answer: When content is presented in a sequence that is different than usual, it’s essential to ensure sequence of content is meaningful programmatically.

Question: Can I color code the information?
Answer: Yes, color can be used to convey information but color must not be the only form of presenting information. Example, accept is marked as “green” button and decline is marked as “red button”, same labels i.e. accept / decline must be provided as a text in addition to color code.

Question: Can I play audio or music automatically on my web page?
Answer: It’s a not a good practice to play audio automatically on a web page; reason being it would disrupt users with screen readers and people who do not expect an audio on loading of a web page. However, if audio has to played automatically and length is more than 3 seconds, controls must be provided to pause or stop the audio.

Question: How can I check for contrast of colors?
Answer: Simple way is to use Color Contrast Analyzer tools. See the list on Accessibility Testing tools section of Our Resources page

Question: How to meet resize text requirement?
Answer: User browser’s default zoom option (mostly CTRL and +) and zoom up to 200%

Question: Can I use images of text?
Answer: Where possible, it’s advisable to use text to convey the information rather than embedding onto an image.

Question: What’s graphics contrast?
Answer: It’s a new Success Criterion – 1.4.12 Graphics Contrast of WCAG 2.1. If information is conveyed only in the form of graphic e.g. charts etc., it must have minimum contrast ratio of 4.5:1.

Web Content Accessibility Guidelines (WCAG) 2.1 First Public Working Draft has been published – have your say!

It was in 2008, Web Accessibility Initiative Group of W3C has announced Web Content Accessibility Guidelines (WCAG) 2.0 as a candid recommendation. Since then, there has beena lot of of improvements and changes in technologies.

For more than a year now, Accessibility Guidelines Working Group have been working hard to introduce extended version of WCAG 2.0; as part of this effort, task forces have formed to work on needs of mobile, cognitive and low vision users.

Yesterday, Working Group has published Web Content Accessibility Guidelines 2.1 First Public Working Draft to see feedback from users across the world.

There are 28 new success criterias in WCAG 2.1; in which 3 have been formally approved by the working group; others are in proposed states. Three new success criterias that got accepted are:

  • Resize content
  • Graphics Contrast
  • Interruptions (minimum)

For this publication, Accessibility Working Group of W3C seeks feedback on following questions:

  • Do the new and proposed Success Criteria address current user needs for web content accessibility?
  • Does conformance to the new and proposed Success Criteria seem achievable and testable?
  • How well do the new and proposed Success Criteria fit with the existing Success Criteria from WCAG 2.0?
  • How completely does the set of new and proposed Success Criteria address current user needs, particularly for users of touch- and small-screen mobile devices, users with low vision, or users with cognitive or learning disabilities?
  • Is the impact of WCAG 2.1 on policies that reference WCAG 2.0 understandable and not disruptive?

So have your say and contribute towards digital more inclusive!