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

W3C

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.

Accessible Rich Internet Applications (ARIA) Working Group of W3C has finalized several documents.

The Accessible Rich Internet Applications Working Group of W3C has finalized following documents:

Below is an excerpt of the announcement from ARIA working group:

The Digital Publishing WAI-ARIA specifications were co-developed with the Digital Publishing Interest Group, which has since become the Publishing Working Group.

WAI-ARIA 1.1 adds a variety of new features that were identified as needs since WAI-ARIA 1.0 was completed. These include a static table model to complement the dynamic grid model provided in WAI-ARIA 1.0, supporting news feeds and modal dialog boxes, better supporting labeling and extended descriptions, allowing authors to indicate keyboard shortcuts and custom role types, and refining the owned roles model and set of properties for many ARIA features. Digital Publishing WAI-ARIA Roles takes this further to provide roles for types of content that often appears in digital publications. Accessibility API Mappings describe how these features should be mapped to the features of Accessibility APIs specific to various platforms that user use to access web content.

WAI-ARIA Authoring Practices 1.1 has undergone major enhancements to reflect this work and provide web content authors with practical guidance about how to use WAI-ARIA in web content, including steps they need to take beyond WAI-ARIA itself to provide full accessibility support. A major part of the document is a set of design patterns for various types of widgets that explain how to create the widget using ARIA features and recommended keyboard interaction to achieve a familiar and predictable user experience; these design patterns are complemented by a comprehensive set of examples with working code that demonstrate the design pattern in action and provide authors a starting point for coding their own versions. The document provides comprehensive guidance about how to make content accessible to keyboard users, and also provides information about when *not* to use WAI-ARIA in preference to native features. Further information about this is available in the blog post:

WAI-ARIA Authoring Practices 1.1 Note helps authors make content accessible

Following the completion of WAI-ARIA 1.1, the Working Group will begin work on WAI-ARIA 1.2, which will focus on defining features that correspond to existing HTML 5 features. This reflects convergence of an accessibility taxonomy for the web across various technologies and will support future scripting and automation of accessibility features. More information about the Accessible Rich Internet Applications Working Group is available from its home page:
https://www.w3.org/WAI/ARIA/

There has been great developments in th4e accessibility space during 2017. Way to go!

Accessibility Conformance Testing (ACT) Rules Format 1.0 First Public Working Draft is now available

Accessibility Testing is critical for ensuring accessibility of any product. Similar to any other testing e.g. performance, functional etc., quality is an essential component for accessibility testing too!

Accessibility Guidelines Working Group has published First Public Working Draft of Accessibility Conformance Testing (ACT) Rules Format 1.0 and accepting comments and feedback by 5th May, 2017.

As the size and complexity of web development is growing, it’s essential to have adequate tools to automate accessibility testing. To make rules universal, there needs a standard specification. That is what ACT Rules format aims to address.

About the ACT framework

There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as WCAG 2.0. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web.

This format is intended to provide a consistent interpretation of how to test for accessibility requirements so as to avoid conflicting results of accessibility tests. It is intended for both manual accessibility tests as well as for automated testing done through accessibility test tools (ATTs).

Describing how to test certain accessibility requirements will result in accessibility tests that are transparent with test results that are reproducible. The Accessibility Conformance Testing Rules Format (ACT Rules Format) defines the requirements of these test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules).

The spec consist of Scope of the specification, ACT rule structure that talks about rule outline, rule description, accessibility requirements, Limitations, assumptions and exceptions, accessibility support; Test subject types, ACT test procedures, ACT data format and Rule Quality Assurance.

Do read through ACT rule format draft and File a issue on github if you have some feedback. Comments that the working group is looking for is about:

  • Does the ACT Rules Format address all the topics that are critical to rule design?
  • Does the section on accessibility support adequately address the topic?
  • Does the section on Accuracy Benchmarking adequately address the topic?
  • Are there improvements to better support developers of test rules to transpose their rules and adopt this format?

As a reminder, last date to submit the feedback is 5th May, 2017.

W3C elects new advisory board.

World Wide Web Consortium (W3C) has just announced it’s new advisory board who plays a key role in providing guidance to the team on strategy, legal matters, conflict resolutions etc.,

The W3C Advisory Committee has filled five open seats on the W3C Advisory Board. Created in 1998, the Advisory Board provides guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. Beginning 1 July 2016, the nine Advisory Board participants are Tantek Çelik (Mozilla), Michael Champion (Microsoft), Virginie Galindo (Gemalto), Jay (Junichi) Kishigami (NTT), Charles McCathie Nevile (Yandex), David Singer (Apple), Léonie Watson (The Paciello Group), Chris Wilson (Google) and Judy Zhu (Alibaba). Many thanks to Soohong Daniel Park (Samsung Electronics), whose term ends this month. Read more about the Advisory Board.

And I would specially want to congratulate two folks; one is Charles McCathie Nevile (Yandex), who I met for the first time at Techshare India 2008 at his capacity as CTO of Opera Software. A highly technical guy with a lot of passion for accessibility. What I like about him is his detailed views on any topics raised in different accessibility forum.

Second person I would like to congratulate is Léonie Watson (The Paciello Group), a great speaker with energy, blogger, again with high technical knowledge.

I’m sure W3C never regrets to have these two awesome people onto the board. Kudos to everyone else too.

Regads,
Srinivasu

Accessibility Round-up 1st August, 2013