We have been doing lot of things for an element like adding or changing the name of the element by using aria-label, adding instructions by using aria-describedby, changing the states like pressed/not pressed, checked/not checked by using other aria techniques. Is it possible to customize the name of role or role of the element? I did not mean from the button to link and vice-versa. I meant different. Let us understand with the scenario what I meant.
For ex: button is the name of the role. is it possible to change from button role to attachment button as name of the role? It is not possible in aria 1.0
Aria 1.1 introduced aria-roledescription property to customize the name of the role. The method is that Put the string or custom text in the aria-roledescription attribute and it would become as a role of the element. Assistive technologies would announce the string as name of the role that is presented in the aria-roledescription but not actual role of the element. Let us understand this better with the same scenario
Button role is the actual role of the element. If I want to change from button role to attachment role then I simply add the string “attachment button” in the aria-roledescription. That is all, assistive technologies would announce it as “attachment button”.
We need to be careful while using this attribute as it suppress the native role of the element and announces the string that is presented in the aria-roledescription attribute as the name of the role.
- Authors should use this property in conjunction with wai aria role or implicit aria semantics.
- Authors should limit the use of this attribute to clarifying non interactive elements such as group or region or to provide the description for a widget.
- Authors should ensure that The value of aria-roledescription is not empty or does not contain only whitespace characters.
Notes for assistive technology vendors
- Assistive technologies SHOULD use the value of aria-roledescription when presenting the role of an element, but SHOULD NOT change other functionality based on the role of an element that has a value for aria-roledescription. For example, an assistive technology that provides functions for navigating to the next region or button SHOULD allow those functions to navigate to regions and buttons that have an aria-roledescription.
When there are set of elements, one among them is active, we have been communicating this state today with one or other techniques to assistive technology users. Techniques that we have been following:
- Using off screen techniques
- Using title techniques
- Removing href attribute or providing role=”presentation” if they are actionable elements
These are the hacking techniques to convey the current state of the element to the assistive technology users.
aria 1.1 introduced aria-current attribute to convey the current state of the element programmatically. We don’t need to use hacking techniques any more. Aria-current is enumerated type and accepts list of token values. They are,
- Aria-current=page, represents the current page within the set of the pages. For ex: in the pagination, we can set this attribute to the page which is currently active
- aria-current=”step”, represents the current step within the process. For ex: in the ecommerse websites, we have checkout process. Typically, checkout process consists of few steps such as billing information, shipping information, payment method, conformation and so on.. we can set aria-current=”step= to the step that is currently active.
- Aria-current=”location”, represents the current location within the context or environment. For ex: in the flow chart, we can set this attribute to the location that is currently active.
- Aria-current=”date”, represents the current date within the collection of dates. For ex: in the calendar, we can set this attribute to the date that is currently active
- aria-current=”time”, represents the current time within the set of times.
- aria-current=”true”, represents the current item within the set
- Aria-current=”false”, does not represent the current item within the set.
Notes for assistive technology vendors
- Any other values apart from the mentioned values should be treated as aria-current=”true” by assistive technologies.
- If the attribute is not present or its value is an empty string or undefined, aria-current state MUST NOT be exposed by user agents or assistive technologies.
- Author should not use Aria-current and aria-selected interchangeably as they are not one and the same and they are different. In few cases, author might have to use both aria-current and aria-selected. For ex:, in the tree view, aria-current is to be used for the currently active page and aria-select to be used for the item that user is navigated to..
- Authors SHOULD only mark one element in a set of elements as current with aria-current.
We have definition role in the aria 1.0 and term role supplements the definition role. Term is nothing but a word or phrase with the corresponding definition and it is related to HTML <dt> tag. Let us take simple example to understand about this roles. Web Accessibility is the term. Provides equal access on the web for all the users including people with disabilities is the definition.
When the term and definition roles are not defined then screen reader does not understand what is term and what is definition over there. Screen reader announces that as paragraph without any semantics and this is a problem.
When term role and definition roles are defined then screen readers are expected to announce like as: “term web accessibility. Web accessibility definition provides equal access on the web for all the users including people with the disabilities”
- Term role should not be used on the interactive elements like links
<div role=”term” id=’test’ aria-describedby=”dfn”>
<div role=”definition” id=”dfn”>
World Wide Web Consortium
We have grid role in the aria 1.0 and we supposed to use this role only for interactive tables. However, we have been using the grid role even for the static tables. The method is that We define grid role and aria-readonly=”true” for the container. When we do so, screen reader announces it as read-only grid. With this announcement, screen reader users understand that it is a static table. Although the actual purpose is solved by using this technique, it is not appropriate method from the standards point of view.
To avoid all the confusions, aria 1.1 introduced table role for static tables and it is equivalent to the html table tag.
- Author should use either row or row group as a children for the table role.
<div role=’table’ id=’test’ aria-rowcount=’3′ aria-colcount=’2′>
wai aria1.1 authoring practices-table
aria1.1-table working example
We have checkbox role in aria 1.0. We have been using this checkbox role for many toggling functionalities irrespective of the visual appearance is.. If the checkbox role is applied for the widgets that looks like on or off then screen reader announce it as checkbox not checked/checkbox checked, , which is not correct interpretation, which Is not appropriate, which is not logical, which is not more meaningful, which Is not more semantical. The reason is that visual appearance is on or off and screen reader announces it as not checked or checked and they do not identical/same. therefore, screen reader user does not perceive the same information as sighted perceives.
ARIA 1.1 Switch role helps to bring the same level of experience to the screen reader users as like how a sighted person perceives. When switch role is applied then screen reader announces as “switch on/switch off”, which is more meaningful, more logical, more appropriate. Switch role is nothing different from checkbox role and only to be used when visual appearance of the element is like on or off. Switch role has on/off values but not check/uncheck. Switch role does not have mixed value.
- Author should use The aria-checked attribute to indicate the input is on (true) or off (false).