Digital A11y

A11Y

Understanding SC 1.4.4 Resize Text

Last Modified on by Leave a Comment

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA).

This success criterion requires that the text – both static and that are part of user interface components that are visible to the users must be resizable (scalable) to 200% without the help of any assistive technologies like screen magnifiers. Even though the user agents like the browsers that meet UAG (User Agent Guidelines) 1.0 bear the responsibility of scaling or zooming the text up to 200%, it is the authors responsible for providing that support to the browsers.

What do I do as the content author?

The authors or developers have to ensure:

  • The content is scalable to 200% without any loss of information or functionality
  • The content or texts do not overlap or become not available to the users
  • The user interface components do not become unusable or inactive.

Who Benefits?

Users with low vision or limited vision who consume the content without any assistive technology but use browsers’ zoom functionality alone.

Points to ponder

  • Where browsers do not support or provide zoom functionality (IE6 as an example), provide alternative CSS for scaling purpose
  • When zoomed to 200%, ensure there is no much of horizontal scrolling ( a best practice)
  • Where lengthy user interface components or content like subject line of an email is there, truncate and provide ways along with the instructions to access the content.
Continue reading Understanding SC 1.4.4 Resize Text

WCAG 2.1 is a W3C Recommendation

Last Modified on by Leave a Comment

Web Content Accessibility Guidelines (WCAG) 2.1 is now a W3C Recommendation. 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.

Publication as a W3C Recommendation finalizes the development process and indicates that the W3C considers the updated guidelines ready for implementation on web content. A WCAG 2.1 press release is available.

New support

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.

Transition from WCAG 2.0

WCAG 2.0 remains a W3C Recommendation. It was designed to be a highly stable, technology-agnostic standard, with informative supporting resources. The Working Group has taken care to maintain backwards compatibility of WCAG 2.1 with WCAG 2.0. All the criteria from WCAG 2.0 are included in WCAG 2.1, so web sites that conform to WCAG 2.1 will also conform to WCAG 2.0. As with WCAG 2.0, WCAG 2.1 will be supported by an extensive library of implementation techniques and educational materials, including Understanding WCAG 2.1 and Techniques for WCAG 2.1. These resources have been redesigned and moved from their previous locations to allow the Working Group to update them on an ongoing, instead of periodic, basis.

W3C encourages organizations and individuals to use WCAG 2.1 in web content and applications, and to consider WCAG 2.1 when updating or developing new policies, in order to better address the needs of more web and mobile users with disabilities.

Process and timeline

The Accessibility Guidelines Working Group (AG WG) met an ambitious timeline and completed the work on schedule. Previously, WCAG 2.0 had taken many years to develop, partly because of its goals to be both technology neutral and future-proofed. For many years after the completion of WCAG 2.0, the Working Group focused on supporting those guidelines through updates to Understanding and Techniques. Over time, though, new technologies and use cases emerged which, while still within the scope of WCAG 2.0, may not have been directly addressed.

To better address a range of issues, the Working Group began to explore updated guidance initially on extensions, and then shifted to a full-fledged dot-release. By this time, the need for new guidance, particularly to address the needs of users of mobile devices, users with low vision, and users with cognitive or learning disabilities, had become more urgent. A timeline was set for WCAG 2.1 that would allow its guidance to be finalized in 18 months, and requirements set to keep its new success criteria within the established WCAG 2.0 framework.

Initial proposals for new success criteria were developed by the Working Group, including task forces focusing on specific areas, which also considered many suggestions for improvement that had been submitted by the public over the years. Once an initial set of proposals was established, the Working Group considered how to incorporate them into the guidelines. Candidate success criteria needed to be clear, realistic both to implement and to evaluate, useful to users, and non-redundant. These characteristics are determined by consensus of the Working Group after careful scrutiny and evaluation. This high bar means that many good suggestions needed to be deferred to future versions of guidelines in order either to await technology advances or provide more time to refine the guidance.

Ultimately, 17 new success criteria were added to WCAG 2.1. Once the final set of success criteria were chosen, they were tested in implementations across different types of websites and web content to ensure they were implementable. We want to thank the implementers worked hard on a short timeline to help the Working Group demonstrate implementability of the success criteria, including ones that were at risk.

Future efforts

Many people hoped WCAG 2.1 would provide more new guidance than it does. The requirement of compatibility with WCAG 2.0 along with the aggressive timeline limited what could confidently be added to it. WCAG 2.1 provides important and timely guidance but is still only a step—the Working Group expects to develop another dot-release, WCAG 2.2, to expand the new coverage even further. WCAG 2.2 may be developed under a similar timeline and requirements set than WCAG 2.1 was, though we plan to refine the process to address process challenges experienced during the development of WCAG 2.1.

In addition to a further dot-release of WCAG 2, the Accessibility Guidelines Working Group has been working in parallel on a more major revision to accessibility guidelines, which would not have the same structure as WCAG 2. Beyond web content, these new guidelines are intended to incorporate guidance for user agents and other tools so requirements that depend on tool support are more clear for authors, and address issues of conformance and testability in a different way from WCAG 2. This is a major multi-year project, which is the reason additional updates to WCAG 2 are needed in the meantime. The plan for new accessibility guidelines (which go beyond simply web content) are still being shaped and while not formally named, the project has been code-named “Silver”. Development has been taking place in the Accessibility Guidelines Working Group via the Silver Task Force, in close collaboration with the Silver Community Group to support broader participation and incubation. Input from broad perspectives is critical to this work, and people representing a broad set of stakeholder groups, including those who work in non-English language environments, are invited to participate.

Contribution

Although the completion of WCAG 2.1 is a major milestone, there is obviously plenty of additional work to do. In addition, W3C is coordinating with national and international regions updating their standards and policies, including the current update of the European Norm (EN) 301 549, and discussions to update the Web accessibility standard in China. The work depends on input from participants and public comments.

The Accessibility Guidelines Working Group participation page provides general information about how to participate in the Working Group, and the instructions for commenting on WCAG 2 documents provides information about how to comment on ongoing work. We hope WCAG 2.1 is received as a useful update to web content accessibility guidance and look forward to collaboration on development of further updates.

Source: W3C Blog

Continue reading WCAG 2.1 is a W3C Recommendation

Understanding SC 1.4.5 Image of text

Last Modified on by Leave a Comment

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: (Level AA)

  • Customizable: The image of text can be
    visually customized
    to the user’s requirements;
  • Essential: A particular presentation of text is
    essential
    to the information being conveyed.

Note: Logotypes (text that is part of a logo or brand name) are considered essential.

This success criterion encourages authors to use text representations wherever possible where they have employed technologies to achieve a visual representation of the same text. For example, a blog post in an organization’s site quotes the CEO from his/her recent address. In order to highlight the quotation, the quotation has been designed with a font that is otherwise unavailable and so the quotation is a JPG or a Bitmap image designed using an external application.

What’s wrong in that?

Well, the following problems would arise for the following user groups:

  • People with low vision who may have reading problems because of the font family, size, color and so on. They can’t change the font, resize the text or customize the image of text
  • People with visual tracking problems who can’t read the image of text because of spacing and alignment and they can’t customize these things
  • People with cognitive disabilities that affect reading.

Must we avoid image of text altogether?

No, WCAG discourages but not dismisses the idea of image of texts. There are some exceptions to consider here:

  • Graphs, diagrams and screenshots which visually convey more than the text
  • Texts that are essential in pictures like logos and brand images
  • Texts that are designed with a specific font family which cannot be reproduced in any other way except for image and/or the author has no rights to distribute the font at all
  • Image of texts which have controls to customize font, size, alignment and spacing.

Points to ponder:

  • Use CSS styled headings instead of Bitmap images
  • Provide site-wide controls to customize the images of texts when there are dynamically generated images of texts
  • Use CSS to specify spacing, alignment, color and the font family of any UI elements, their texts and icons, quotations etc
  • Use keyboard generated symbols wherever possible instead of making them as images.

Let there be beautiful visual presentations; let there be texts and let there be customizations too for convenient reading and experience!

Leave your comments and questions as food for our thoughts!

References

Understanding Success Criterion 1.4.5

Continue reading Understanding SC 1.4.5 Image of text

Understanding SC 2.1.1 Keyboard

Last Modified on by Leave a Comment

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. (Level A)

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

This success criterion requires that all functionalities must be accessible and operable to users using a keyboard. Normally users with disabilities & elderly people depend a lot on keyboard to navigate to all parts of the web page & if any part of the web page is not operable with keyboard then it fails this check point. People generally use tab to move forward, shift+tab to move backward & screen reader users use arrow keys a lot to navigate. This success criterion addresses the needs of people with motor disabilities, visually challenged users & elderly users.

Points to Remember

  • Make sure all elements on the page buttons, links, form controls etc. are reachable by tab key.
  • Make sure that users are able to activate the buttons, links & form controls using the enter and/or spacebar keys.
  • Write clean HTML & CSS as it is keyboard operable by default & doesn’t require any special tweaks.
  • Make sure that there is a visible focus for all the active elements on the page.
  • Make sure that focus order is logical & intuitive.
  • Provide tabindex=0 for custom UI elements so that they are focusable.
  • Provide appropriate event handlers for custom scripted elements so that they are operable by their respective keys.
  • Avoid access keys if possible. If not, at least, ensure they don’t conflict with the user agent and/or AT shortcut keys.
  • Make sure that there is no time limit to perform any action using the keyboard when more than one key is required to operate a control.

References

Understanding Success Criterion 2.1.1

Continue reading Understanding SC 2.1.1 Keyboard

Understanding SC 2.1.2 No Keyboard Trap

Last Modified on by Leave a Comment

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, the user is advised of the method for moving focus away. (Level A)

Note: Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion.

This success criterion requires that websites must not trap keyboard users in a particular portion of the page or on a form control. Keyboard users navigate the page using tab key. If the keyboard user is trapped in a particular location & is unable to move forward or backward using the navigational keys such as tab or shift+tab & user is forced to use a mouse to move keyboard focus then it fails this check point.

Points To Remember

  • Make sure that users can tab to & away from all parts of the site.
  • If a user is trapped on a portion of the web page for a purpose, a clear instruction must be provided for the user to end that keyboard trap.
  • Check if all parts of the site is operable using only keyboard, test by unplugging the mouse.
  • Stick to standard navigation as much as possible like tab, shift+tab & arrow keys.
  • If custom keystrokes are provided to operate a control make sure hints are exposed to all users.
  • Make sure your third party widgets are accessible, most of the time they cause major keyboard operability issues.

References

Understanding Success Criterion 2.1.2

Continue reading Understanding SC 2.1.2 No Keyboard Trap

Links VS Buttons: A Perennial Problem

Last Modified on by 2 Comments

Once a friend told me about a site and asked me to sign up to do some course. He told me that “Sign up” was a link that I needed to click to register myself on the site and do the course. I pulled the links list in my screen reader and searched for some time. Alas! I found nothing. Out of frustration and desperation, I tried for buttons and there it was – “Register button”.

Now, was my friend wrong in guiding me? Or was the screen reader wrong? Or was I wrong in understanding his instruction? Well, it could be either one of them; all of them or none of them at all.

My friend is visually right as he sees the element that looks like a link. The screen reader is technically right as somewhere the code says that it is a button. The only problem is that a button is styled as a link but coded as a button.

A link or a button: Does it really matter?

When an element is operable, it doesn’t matter in a normal circumstance. But certainly it matters to assistive technologies and the people who use them.

When and where do we use a link or a button?

Usability experts offer the following explanation in this regard:

  • Use buttons when the user- action causes a change in either back-end or the front-end of the website. For example, submitting a form, opening a pop-up or a modal or a pannel on the same page.
  • Use links when the user-action doesn’t affect the website at all. In this, the users are just readers or spectators of the site. For example, to navigate to the next page or an external source after viewing the content of the page.

This is just usability. When it comes to accessibility, when an element looks like a button or link, use the respective markup to mark its role. That would help the assistive technologies like screen readers and speech recognition software like “Naturally Dragon” to expose appropriate roles to the users.

Use native markup

An anchor <a> gives the following advantages:

  • Navigates to new pages
  • Allows browser refresh
  • Supports opening in new tab/window
  • Provides with default tab focus with (href) attribute
  • Supports in-page skips with internal href attributes
  • Provides with implicit role (link role) to sscreen readers
  • Shows active, visited, hover and focus.

Buttons <button>:

  • Have default keyboard focus
  • Are activatable by space key
  • Provide with implicit role (button) to screen readers
  • Can be disabled
  • Submit and reset forms, open modals and expand/collapse panels.

At any point, native markups have much more to offer to the developers and the users than the custom controls.

Points to remember:

  • Design with best usability and accessibility practices
  • Complement the style with the appropriate and semantically correct code
  • Ensure whatever element you use, the implicit role matches with the element’s look
  • Use ARIA roles like (role=button” or (role=”link” to maintain the semantic role when all efforts to maintain native markup fail.

Link or button, let that be inclusive and convey the same meaning to everyone.

This is just an attempt to put things to perspective. If you have comments, suggestions and/or opinions, we welcome with open hands!

Continue reading Links VS Buttons: A Perennial Problem