Skip to main content

Tagged as

aria

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

December 15, 2017 Srinivasu Chakravarthula 1 comment Accessibility News ,

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!

WAI – ARIA Landmark navigation extension

May 15, 2017 Srinivasu Chakravarthula Leave a Comment Web Accessibility ,

Web Accessibility Initiative (WAI) of W3C, a few years ago, introduced landmark roles (also known as landmarks”) for easy navigation of web page. An introduction to ARIA landmark roles:

The purpose of this technique is to provide programmatic access to sections of a web page. Landmark roles (or “landmarks”) programmatically identify sections of a page. Landmarks help assistive technology (AT) users orient themselves to a page and help them navigate easily to various sections of a page.

They also provide an easy way for users of assistive technology to skip over blocks of content that are repeated on multiple pages and notify them of programmatic structure of a page. For instance, if there is a common navigation menu found on every page, landmark roles (or “landmarks”) can be used to skip over it and navigate from section to section. This will save assistive technology users and keyboard users the trouble and time of tabbing through a large amount of content to find what they are really after, much like a traditional “skip links” mechanism. (Refer to User Agent Notes above for specifics of AT support). A blind user who may be familiar with a news site’s menu, and is only interested in getting to the top story could easily navigate to the “main” landmark, and bypass dozens of menu links. In another circumstance, a user who is blind may want to quickly find a navigation menu, and can do so by jumping to the navigation landmark.

If you are a screen reader user, it’s rather easy to use landmarks using keyboard commands provided by screen reader. But what if you are not a screen reader user? Recent post by Matthew Atkinson of The Paciello Group titled Improving access to landmark navigation has introduced a browser extension that works greatly for non-screen reader users to benefit from landmarks on any web page and browse the page in an easy way. I have installed on Firefox and experience is pretty smooth. All user needs to do is load a web page of choice and click on Landmark navigation extension; displays list of available landmarks as shown in below image.

Screenshot of landmarks showing on ServeOM Inclusion Home page
Screenshot of ServeOM Inclusion home page showing available landmarks using Landmark Navigation extension on Firefox
.

Download and install the landmark navigation extension for Firefox, Chrome and/or Opera to tryout yourself.

Wish to know what are the ARIA landmark roles? Read Landmark roles section on WAI-ARIA spec

Creating Accessible Forms

January 20, 2016 Srinivasu Chakravarthula Leave a Comment Presentations, Web Accessibility , , ,

Overview

This has been presented as 4th Learning Session to the members and guests of W3C Accessibility in India Community Group. Objective of these learning sessions is to raise awareness about accessibility and enhance network of accessibility professionals.

Slides

Below are the slides presented in the session:

Text Transcript

Hello everyone, Thank you for joining us. In this session, we will be talking about Creating Accessible forms. Agenda of this session will be:

Agenda

  1. About Deque and Me
  2. Setting the Context – Forms
  3. Remembering Basics
    1. Associated Labels
    2. Group Level Form Controls
    3. Labels and Instructions
  4. Making Dynamic and Complex Forms accessible
  5. Error handling and prevention
  6. WCAG 2.0 Success Criteria related to forms
  7. Resources
  8. Questions

About Deque

Deque is a global leader in the area of Accessibility serving Government, Corporate and other organizations for 15+ years. Digital Accessibility is both our mission and vision.

About Me

Am an accessibility evangelist with a decade+ of experience. Started my accessibility journey at BarrierBreak, then worked at several organizations including Yahoo!, PayPal, HCL Technologies and currently works at Deque. Accessibility is not just my profession but something very close to my heart. My hobbies include networking, swimming, playing Chess and Carrom. Currently I live in Hyderabad with my wife Hema and our cute daughter Khushi Varshini.

Setting the context – Forms

Today digital forms are playing a key role in people lives. They are everywhere from school admission to avail retirement benefits. It’s encouraging to see even Government is promoting use of digital services. Moving to digital would be an added benefit to people with disabilities and make them less dependent. They are also safe and secure way to store and easy to retrieve.

Basics – Associated Labels

It’s essential that all form controls are programmatically associated with their respective labels. This can be achieved by using <for> and <id> attributes, <aria-label> or <title> attribute.

View Form Label example

References for Associated Labels:

  1. W3C – WAI’s tutorial on Form labels
  2. Technique H44: Using Label elements to associate text labels with form controls
  3. Technique G131: Providing Descriptive Labels

Basics: Group level form controls

When user has to select options that are provided in the form of radio buttons, checkboxes or when there are a group of form controls such as Date of birth, phone number; those controls usually have a common label. In such a situation, it’s essential to ensure that:

  1. All form controls are programmatically associated with their labels
  2. All form controls are programmatically associated with their common label

View Radio button example

References for Group level form controls

  1. Technique H71: Providing a description for groups of form controls using fieldset and legend elements

Basics: Labels and instructions

It’s recommended that forms labels are visible. Now-a-days, placeholder text is used as form label; but this is not a good practice unless there is a mechanism to make label still visible even when user has inserted data into input field. Otherwise, it would be difficult for several users including those with cognitive disabilities to review the information before submitting.

It’s also important to provide instructions about required fields, if input field accepts data only in specific format or any other information that user should know while filling out the form.

Resources for Labels and instructions

  1. Understanding SC 3.3.2: Labels and Instructions

Dealing with Dynamic and Complex Forms

I’m going to demonstrate you all 3 examples:

  1. Creating Accessible Date Picker where the date picker is completely accessible using keyboard and not with mouse alone, all dates have descriptive labels for user to select
  2. Now-a-days, e-Commerce is trending and often the challenge is to deal with Shopping cart. Shopping carts usually gets updated dynamically as user makes selection of a product. So it’s essential that user gets the updated information about pricing, quantity added, total number of products in the cart etc., So let’s look at an Example of Accessible Shopping Cart <aria-live> tribute plays a key role to make such applications accessible.
  3. Another interesting widget would be Character count. We see several applications will have <texture> input field that allows only a limited number of characters can be inserted. In this case, user should be informed about permitted number of characters along with the <label> and alert user when nearing to end of allowed number of characters. It’ would be annoying to to expose character count right from first character. View Example of an Accessible Character Counter

Error handling and prevention

It’s important that there is a mechanism to identify mistakes that user has made on form submission. It’s also important error messages are conveyed via multiple clues including through text and styling input fields that requires correction.

It’s essential to enable users to prefer from making mistakes. To address this, user should be provided helpful information along with form label for potential fields that require user to input in specific format. For instance, Date of birth field accepts in a specific format or in a user registration form, password field may have some conditions. These need to be informed to user.

Resources for Error handling and prevention

  1. Understanding SC 3.3.1: Error identification
  2. Understanding SC 3.3.6 – Error prevention

WCAG 2.0 Success Criteria that are related to Forms

  1. 1.3.1 Info and Relationships: Information, Structure and relationships conveyed through presentation can be programmatically determined or are available in text (Level A)
    1. Associate labels either explicitly or implicitly
    2. Ensure that group related form controls are marked up using <fieldset> and <legend>
  2. 2.4.6 Headings and Labels: To describe topic / purpose (Level AA)
    1. Provide descriptive labels
    2. Provide visible labels
  3. 3.3.2 Labels or instructions: Labels or instructions are provided when content requires user input (Level A)
    1. Identifying required field
    2. Error identification
    3. Providing instructions
  4. 4.1.2 Name, Role and 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. (Level A)

Resources

I have put together some great resources including Code Examples from our Deque University, a nice tutorial from W3C, a couple of articles from WebAIM and my good friend Rakesh.

View Resources

Thanks everyone for attending and looking forward to see web more inclusive. Do feel free to reach out to me for any questions / comments.

Common mistakes of that a web developers make

October 3, 2010 Srinivasu Chakravarthula Leave a Comment Web Accessibility , , , ,

Most developers feel making a website accessible require an additional effort, time consuming and needs to write a lot of additional code; which is actually not very true. But yes, there are certain additional things to be done, but they are most times enhancements. Having said that, most of the efforts that require to make a website accessible are the best practices of HTML. Here, I will endeavor to illustrate some of the common mistakes that a web developer commits.

  • Provide inappropriate page titles or provide a common title for all the pages across the website something like the name of the organization without the respective page title
  • Do not declare doctype External Website of the document
  • Do not define language of the document
  • Do not provide text alternative to non text elements such as images, CAPTCHA, audio etc.
  • Do not markup the headings in the documents
  • Use table attributes for the layout purpose
  • Do not mark up table summary, table headers
  • Do not mark up associated labels for form fields using “for” and “id” attributes
  • Do not provide site map to the website
  • Do not use accessibility techniques while using Java script, Flash etc.

Best reading…

Writing accessible HTML forms

August 8, 2010 Srinivasu Chakravarthula Leave a Comment Web Accessibility , , , , , ,

We fill a lot of forms on the web on daily basis – may it be for a bank transaction, booking of travel, shopping etc. Often we see forms looks very beautiful but in reality, most of them are not beautiful due to lack of associated labels. Oh! wait, we know, you are about to shown on us and say that you have never seen a form just with input elements and without text labels, you are right, but did you ever see a form with a text browser or with a screen reader. Here is an exercise for you before reading this article:

  1. Download NVDA External link Screen reader and install on your Microsoft Windows machine
  2. Open your web browser perhaps Mozilla Firefox and visit the APSRTC‘s New Registration Form External Website and you should see a beautiful form like below.

    APSRTC New Registration form

  3. Press “F” key on your keyboard to reach to the first form field and then navigate the form using “tab” key; ideally you should hear something like “Username:edit, Password: password edit, Confirm password: password edit, Personal information, Firstname:edit” and so on. But you will hear something like “Table with 16 rows and 2 columns, row two, column two edit” and so on… and here is how this form looks on a text browser:
    Text version of APSRTC Registration form

Now, let’s see what are the issues with above form. Firstly, screen reader is reading number of rows and columns, since the APSRT did not use CSS to control the layout of the form but have used <table> attributes to control the layout. Well, screen readers has the capability to turn off reading the layout tables but some users may not be aware of this option. Also, it is not recommended to use the table attributes to control the layout.

Second problem is that screen reader is unable to read the labels of the form since associated label “for” and “id” attributes are missing. Besides screen readers and text browsers, even search engines treat those form fields with no labels. Here are some ground rules to make accessible forms.

  • Provide necessary instructions before the form states
  • Do not indicate mandatory fields in form of color alone
  • If a form field is a required field, inform the same to the user along with form label
  • Provide associate labels to the form fields
  • Use appropriate “fieldset” and “legend” attributes for check boxes and radio buttons
  • If you opt to use image button, remember to provide alternate text
  • If the form is dynamic, use ARIA labels, roles and states as appropriate

Related links: