Combobox role

Description

As you may have seen, most of the forms on the website contain auto suggestion characteristics/features. Let me explain this with simple example. While typing any string in the google search text field, it displays some list of the suggestions dynamically, and this behavior is nothing but auto suggestion behavior. This particular behavior is just not limited to the google search text field but there are many input fields on the web that has these auto suggestion characteristics. Since these auto suggestions are most of the places on the web these days, imagine if these auto suggestions are not accessible to the people with the disabilities. When these auto suggestions are not accessible then it is going to create huge problem to the people with disabilities.

In order to address this problem, ARIA introduces the combobox role. When the combobox role is applied along with required ARIA attributes for the widget that has auto suggestion characteristics then keyboard and screen reader users would get seamless experience. However, it is not that easy to construct accessible auto combobox/auto suggestion widget. Constructing an accessible combobox is one of the trickiest things in the ARIA. The reason is that authors might have to apply multiple ARIA attributes, java script, focus management and so on… at the same time to construct accessible combobox. While applying various techniques at the same time, it is highly possible that authors make mistakes if they are not careful.

That said; let me tell what combobox role is all about with the technical terms. A combobox is a composite widget made up of the combination of two distinct elements: 1) a single-line textbox, and 2) an associated pop-up element for helping users set the value of the textbox. The popup may be a listbox, grid, tree, or dialog.

It is very commonly misunderstood that both ARIA combobox role and HTML select element are one and the same because most of the screen readers interpret both of them as combobox. Although ARIA combobox role and HTML select element are being interpreted as comboboxes by most of the screen reader users, they are not identical but they are similar. The one significant distinct feature between both of them is that ARIA combobox role would contain textbox element whereas HTML select would not contain the textbox element. As per the analysis and my understanding, ARIA listbox role and HTML select are one and the same. In fact, ARIA listbox role contains much more features than HTML select and will discuss more about listbox role in the future blog posts.

Author notes

  • Combobox role must contain or must own a text input element with role textbox or searchbox or native input text field and that the text input has aria-multiline set to false.
  • Aria-Autocomplete attribute must be set with appropriate value (inline, list, both, and none) on the textbox element based on the nature of the suggestion and how those suggestions are presented. Elements that support aria-autocomplete have an implicit aria-autocomplete value of none and the below is the brief description of each aria-autocomplete value. We will discuss about this attribute in details in the future blog posts.
    • While user is typing some string on the text input, it displays the corresponding suggestions in the popup element. If text input gets auto filled  with the first suggestion from the list of the suggestions then set aria-autocomplete=”inline”
    • While user is typing some string on the text input, it displays the corresponding suggestions in the popup element. If user has to select suggestion manually  from the list of the suggestion then set aria-autocomplete=List”
    • While user is typing some string on the text input, it displays the corresponding suggestions in the popup element. If text input gets auto filled  with the first suggestion from the list of the suggestions and suggested string can be selectable then set aria-autocomplete=”both”
    • While user is typing some string on the text input, it displays the same set of the suggestions in the popup element irrespective of the string that user has typed. If these type of behavior is present then set aria-autocomplete=”none”
  • Authors must ensure that that only textbox is visible when the combobox is in the collapsed state and Elements with the role combobox have an implicit aria-expanded value of false
  • Authors must set the value of aria-expanded as true when textbox and secondary element that serves as its popup are visible.
  • Authors MUST ensure it contains or owns an element that has a role of listbox, tree, grid, or dialog when combobox is expanded.
  • Authors MUST set aria-controls on the textbox element to a value that refers to the combobox popup element.
  • Authors must set the value of aria-has popup based on the type of popup element as combobox popup element can be grid, tree, dialog, listbox and Elements with the role combobox have an implicit aria-has popup value of listbox.
  • Authors may set aria-activedescendant on the textbox element if the popup element supports aria-activedescendant and the value of aria-activedescendant must refer to the active element that is in the popup while DOM focus remains on the textbox element. It is important to remember that whenever aria-activedescendant attribute is being set on the textbox element then literal DOM focus does not need to move to the elements contained in the popup to navigate within the popup elements and the DOM focus can remain on the textbox element. There is much more to understand about aria-activedescendant attribute and will discuss in details about this attribute in the future blog posts
  • Authors may set aria-owns attribute on the combobox element if DOM hierarchy cannot be used to represent the relationship and the value of aria-owns must refer to the popup element

Code snippet

<div aria-label=”Tag” role=”combobox” aria-expanded=”true” aria-owns=”owned_listbox” aria-has popup=”listbox”>

    <input type=”text” aria-autocomplete=”list” aria-controls=”owned_listbox” aria-activedescendant=”selected_option”>

</div>

<ul role=”listbox” id=”owned_listbox”>

    <li role=”option”>Zebra</li>

    <li role=”option” id=”selected_option”>Zoom</li>

</ul>

Complimentary info on the combobox role

The combobox role and aria-owns attribute must be set on the textbox element as per the ARIA 1.0 whereas the same combobox role and aria-owns attribute must be set on the container that is the parent of the textbox element as per the ARIA 1.1. To know more about how to set the combobox role and aria-owns in the ARIA 1.1, please look at the code snippet section of this post. Although ARIA 1.0 is obsolete, user agents, assistive technologies, and conformance checkers SHOULD continue to support the ARIA 1.0 pattern so that existing implementations of the ARIA 1.0 pattern remain functional.

References

WAI ARIA global attributes

Overview

WAI ARIA global attributes(states and properties)  are the attributes that can be defined for any host language element whether role is applied or not. Let me explain this with simple example. Aria-label(property) is the global attribute as per the specification. Since aria-label is global attribute, author can define this attribute for any host language element(such as <div>, <span>, <a>, <button>, and so on..). Apart from that, global attributes are also applicable for any base roles (such as role=”link”, role=”button” and so on..). To put it in the technical terms, global attributes inherits into any host language elements as well as any ARIA roles. The following are the list of the global states and properties’ that are applicable for any base markup and any role. This list is based on the aria 1.1 specification and this list may subject to change depending on the future versions of aria

  • aria-atomic
  • aria-busy (state)
  • aria-controls
  • aria-current (state)
  • aria-describedby
  • aria-details
  • aria-disabled (state)
  • aria-dropeffect
  • aria-errormessage
  • aria-flowto
  • aria-grabbed (state)
  • aria-haspopup
  • aria-hidden (state)
  • aria-invalid (state)
  • aria-keyshortcuts
  • aria-label
  • aria-labelledby
  • aria-live
  • aria-owns
  • aria-relevant
  • aria-roledescription

Complementary info on the aria global attributes versus presentational role

As discussed in the none role/presentational role blog post, presentational role negates the element semantics. However, there is an exception to this. The exception is that When presentational role(role=”presentation”) is defined on the element that has implicit native semantics as well as the global attributes then assistive technologies ignore the presentational role and exposes the element’s role/semantics. Let us look into this with sample code snippets.

Sample code snippet

<!—1. [Role=”presentation”] is ignored due to the global aria-haspopup property and as a result, assistive technologies expose the heading semantics. –>

<h1 role=”presentation” aria-haspopup=”true”> Sample Content </h1>

<!– 2. [Role=”presentation”] negates the both the implicit ‘heading’ and the non-global level as there are no global attributes. –>

<h1 role=”presentation” aria-level=”2″> Sample Content </h1>

References

Rules of ARIA

Overview

Before we dive into the rules of the ARIA, let me reiterate what ARIA is going to do. ARIA stands for accessible rich internet applications and it defines the way to make the web content or web applications more accessible to people with the disabilities.

Even though ARIA has evolved couple of years ago, still some of the developers misuse the usage of the ARIA due to the lack of thorough knowledge . Misusing of the ARIA results much more damage to the web page in terms of it’s accessibility. That is the reason there is saying “No ARIA is better than bad ARIA!“. Having said that, if developers understand and follow the rules of the ARIA then definitely it is going to help to certain extent in avoiding some of the mistakes. Let us understand what are those rules of the ARIA in details.

Rules of the ARIA

Rule1: don’t use ARIA, use native HTML instead

The first rule talks about use native HTML elements or attributes to convey the semantics to the people with the disabilities. In the case, the semantics that you are looking for is not available in the HTML then use ARIA. Let me explain this with the example. To construct the checkbox on a web page, use HTML checkbox(<input type=”checkbox”>) but do not use ARIA checkbox(<div role=”checkbox”>…</div>). The reason is that HTML checkbox conveys the semantics to the people with disabilities without any additional effort as it is already mapped to the accessibility APIs. Now the question is when to use ARIA. There are some scenarios where we might have to use ARIA and they are:

  • When the website is not designed from the scratch and is being retrofit for an accessibility then it is better to use ARIA in order to save time, effort,  and money
  • If it is not possible to style the native element as per need for some reason(exceptional cases)  then it is ok to construct the custom element and style as per the need and provide the semantics to the element by using ARIA
  • If the required semantics are not present in the host language(HTML 5.x) then use ARIA to communicate the semantics. For the instance, one needs to use ARIA to convey the tree semantics as there is no such equivalent HTML element or attribute.
  • When the user agent support of some of the HTML 5.x is not great then use ARIA without any second thought.

Rule2: Do not change native semantics, unless you really have to.

As discussed earlier, most of the HTML elements or attributes convey one or other semantics. We are not supposed to change the native semantics unless it is really essential. For example: Developer wants to build a heading that is  a tab

Do not do this:

<h2 role=tab>heading tab</h2>

Do this:

<div role=tab><h2>heading tab</h2></div>

Rule3: All interactive ARIA controls must be usable with the keyboard.

Providing the ARIA roles would bring the semantics to the custom control but it would never bring control to work as expected with the keyboard. We need to remember that ARIA is nothing to do with the keyboard functionality and is just to provide the semantics to the accessibility APIs. Being said, it is developer responsibility to make the custom control accessible with the keyboard by using some scripting. For example, if we construct the custom button(<div role=”button”>) then we need to  make sure that it receives the focus and user is able to activate the associated functionality by using both enter and space keys. To put it simpler, custom button should work with the keyboard as how native button works.

Rule4: Do not use role=”presentation” or aria-hidden=”true” on a focusable element

Role=”presentation” or role=”none” is to negate eh semantics from the accessibility tree and the element that has role= “none” is not supposed to be an interactive in any way. On the similar lines, Aria-hidden attribute is to hide the content or element from the accessibility APIs and the element that has aria-hidden set to true is not supposed to be an interactive in any way. Defining either of these attributes on the visible focusable elements results some users focus nothing.

Do not do this:

<button role=presentation>press me</button>

Do not do this either:

<button aria-hidden=”true”>press me</button>

<button aria-hidden=”true”>press me</button>

Do this:

<button role=”presentation” tabindex=”-1″>Don’t Click Me</button>

<button aria-hidden=”true” style=”display: none;”>don’t Click Me</button>

Rule5: All interactive elements must have an accessible name.

All interactive elements(such as links, buttons, text fields, combo boxes, radio buttons, checkboxes and so on..) on a web page must have accessible name. Without accessible name, assistive technologies do not understand what the control is all about. To provide the accessible name, there are techniques available and they vary from control to control. Let us look some of them.

  1. HTML links and buttons: whatever the link text/button value that we provide, it becomes the accessible name
  2. Input text fields: in order to provide the accessible name, form controls need to be associated with it’s visible label  either implicitly or explicitly.

    For example: The below input text field has visible label but there is no accessible name

    First name<input type=”text”>

    The below input text field have both visible label and accessible name. Accessible names establishes with the for and ID connection

    <label for=”fname”>First name</label>

    <input type=”text” id=”fname”>

  3. Custom widgets: in order to provide the accessible name for the custom widgets, authors can use either aria-label or aria-labelledby techniques

References

None role

Description

None role(role=”none”)  in aria1.1 is nothing different from presentation role(role=”presentation”) in aria1.0 and they both are one and the same. Presentation/none role to be used in order to hide the semantics to the assistive technology users. For some reason, authors/developers are getting confused with the term “presentation” as well as the intended meaning of presentation role. Many authors started thinking that both aria-hidden and presentation role are one and the same but it is not true. To put the things simpler, aria-hidden attribute is to hide the content from the assistive technology users whereas presentation role is to hide the semantics(role) from the assistive technology users. Aria-hidden attribute and presentation role are meant to serve the different purposes. In any case, let me not confuse you more about aria-hidden attribute over here and will cover aria-hidden attribute separately in the future blog posts.

To avoid all the confusions surrounded with the term “presentation”, aria1.1 introduce new role called none role. The term “none” itself conveys that element would not have any role and none is the synonym of presentation. The specification believes that the term “none” would not confuse the authors/developers any more. Till the support of none role is robust, authors are advised to use the presentation role only. When none role is applied then element semantics and any of it’s children semantics are going to be removed from the accessibility tree and this would be better understood in the coming sections. However, the content and the descendants elements are going to remain the same in the accessibility tree

The major difference between all other aria roles and the none role is that all other aria roles are used to convey the semantics whereas none role is to not to convey the semantics. The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type. You might be wondering in which situations we might have to use none role. There are certain scenarios where reading the semantics to the screen reader users would create the problem in understanding the page structure. In addition, reading the semantics that are for layout purposes would result too verbose for the screen reader users to understand the things properly on the page. Let us discuss some of those  scenarios

Scenarios to use role=”none”

  1. There is text with heading mark-up but this text is not heading visually, logically, and functionally on the page. Having heading mark-up to that text would create a problem in understanding the page structure to the screen reader users. Authors need to remove heading mark-up. In order to remove the heading mark-up, authors either can remove heading tag from the DOM or  can use role=”none”
  2. There is image that is used for the decorative purpose. Screen readers must ignore the decorative images. For the screen readers to ignore the decorative images, authors either need to set alt as null(alt=””) or use role=”none”
  3. There is content with table mark-up but this table is for the layout purpose. Having table mark-up for that content would cause confusion to the screen reader users. Authors need to remove table mark-up. In order to remove the table mark-up, authors either can remove table tag and it’s children from the DOM or  can use role=”none”. The important point to remember here is that table semantics and it’s children semantics(such as <th>, <tbody>, <tr>, <td> and so on..) are going to be removed from the accessibility tree when role=”none” is applied.

Author notes

  • Authors must not use role=”none” on the interactive or focusable elements
  • Authors must not use role=”none” on the element that has the WAI ARIA global attributes(ex: aria-haspopup). If authors do so then user agents ignore the presence of the role=”none”
  • Authors can also set role as “none presentation” for backward compatibility

Sample code snippet

If given

<ul role=”none”>

  <li> Sample Content </li>

  <li> More Sample Content </li>

</ul>

Then assistive technologies like screen reader would not announce the list semantics

References

ARIA 1.1 overview

Description

the modern web is becoming more and more rich from day by day but at the same time it is becoming more and more complex in terms of accessibility.  To address the accessibility challenges of modern web, ARIA has evolved. ARIA stands for accessible rich internet applications and it defines the way to make the web content or web applications more accessible to people with the disabilities. It helps especially with dynamic content and advanced controls(such as tree, menu, slider and so on..) developed with the various technologies(ajax, java script, and so on..). before aria, it was tough for the screen reader users to understand what was going on in the dynamic web application.

WAI ARIA1.0 has become w3c recommendation on 20th march 2014. After 3 and half years, WAI ARIA1.1 has become w3c recommendation and it is on 14th dec 2017. ARIA1.1 extends version 1.0 and provides no of additional features to continue bridging the gap for accessibility in html.

 

What’s new in the aria1.1

8 new roles (now 81 total)

The following new roles have been added

  1. cell
  2. Feed
  3. Figure
  4. Table
  5. Term
  6. none (synonym for presentation)
  7. Searchbox
  8. Switch

 

13 new states & properties (now 48 total)

The following new states and properties have been added

  1. aria-colcount(property)
  2. aria-colindex(property)
  3. aria-colspan(property)
  4. aria-current(state)
  5. aria-details(property)
  6. aria-errormessage(property)
  7. aria-keyshortcuts(property)
  8. aria-modal(property)
  9. aria-placeholder(property)
  10. aria-roledescription(property)
  11. aria-rowcount(property)
  12. aria-rowindex(property)
  13. aria-rowspan(property)

 

8 roles with major updates

The below roles have been updated in terms of it’s usage

  1. Application: it is not a landmark and needs to be thought as last option
  2. Article: along with the original behavior, in addition, it is the child of feed role
  3. Combobox: it should also own an element that has a role of tree, grid, or dialog along with the role of listbox.
  4. Dialog: it should be considered as a window and assistive technologies should not pass through keys.
  5. Document: it is Recommended to use inside application elements.
  6. Grid: spec provides the additional guidance on how focus management should be, and how aria-readonly should be used
  7. Region: it should be considered as a landmark
  8. Separator: If focusable, it should be widget requiring aria-valuenow, aria-valuemin, and aria-valuemax, supports aria-valuetext.

 

11 states & properties with significant changes

The below attributes have been updated in terms of it’s usage

  1. aria-activedescendant: editorial change
  2. aria-autocomplete: editorial change
  3. aria-busy: it should not be limited to live regions
  4. aria-haspopup: it should support additional values such as menu, grid, dialog, tree, listbox along with the original values(true/false)
  5. aria-hidden: editorial change
  6. aria-level: it should be required for the heading role
  7. aria-orientation: default value should be undefined and it is allowed for more roles
  8. aria-readonly: it should support other roles too such as combobox, listbox, radiogroup, slider, and spinbutton.
  9. aria-posinset: it should Support other roles too such as radio, tab, article in feed.
  10. aria-setsize: it should Support other roles too such as , radio, tab, article in feed.
  11. aria-setsize: the value should be set to “-1” if the size is unknown.

 

Deprecations

The following attributes have been deprecated in aria1.1

  1. aria-dropeffect
  2. aria-grabbed

 

references

  1. aria1.1 specification: c. change log