Tag: aria

Description

As we discussed in the past, assistive technologies like screen readers may not be able to notify the changes that are happening elsewhere on the page while user is going through the web content at his/her own pace unless live region is set. As part of live regions, we covered the aria-live and aria-atomic in the past. Let us understand about aria-relevant as part of this blog post. Live regions may contain multiple changes and all of them may or may not be required for the user to notify. To control these multiple changes, authors can use aria-relevant attribute. Let me give an example. Imagine there is chat log. As soon as there is new message in the chat log, user should be notified about this change because it is relevant in this contexts. Similarly, previous chat messages sometimes may be removed from the chat log to accommodate new chat messages in the log. However, this particular change need not to be notified to the user as it does not have any meaning.

To put it simpler, Aria-relevant is an optional property for aria-live and it basically talks about what type of changes to be notified to the users within the live region. Aria-relevant accepts list of token values such as additions, removals, text, additionstext, all.

 

Author notes

 

• Aria-relevant can be used on any base markup and it is the global attribute
• The default value of aria-relevant is additionstext for all elements. This means that authors can leave aria-relevant to it’s default value if assistive technologies to notify about the new node as well as modified node text/modified image alt text within the accessibility tree
• Authors can set aria-relevant to additions if assistive technologies to notify about the new node
• Authors can set aria-relevant to removals if assistive technologies to notify about the removal node
• Authors can set aria-relevant to text if assistive technologies to notify about the modified node text/modified image alt text
• Authors can set aria-relevant to all if assistive technologies to notify about all the changes such as new node, removed node, modified node text/modified image alt text

 

 

Sample code snippet

<ul aria-live=”polite”

aria-relevant=”additions”>

<li>Item 1</li>

<li>Item 2</li>

<li>item 3</li>

</ul>

 

 

Complimentary info on aria-relevant

The removals value of aria-relevant attribute should be used sparingly. In other words, Authors should

not use removals value in all the contexts rather authors should use removals value whenever it makes sense for the user to notify about the removed content. To give you an example, it is important/relevant  for the user to notify about who left the meeting in the virtual meeting/conference.

Another important point to make a note of removal value is that most of the screen readers except voice over do not have great support on removal value as of now.

 

References

• WAI ARIA 1.1 specification: aria-relevant(property)

 

 

 

 

 

 

 

A Quick recap

This is the continuation of part1(what’s probably going to come in ARIA1.2-part1) blog post and we pretty much covered the new roles(such as blockquote, caption, code, deletion, insertion, and so on..)  that are probably going to come in the ARIA1.2 as part of the previous blog post. Let us look into the changes that are probably going to take place on the existing attributes and roles usage in this part2 blog post.

 

Changes that are probably going to take place on the existing roles and attributes usage

Combobox(role)

There are significant changes that are going to take place for combobox role(role=”combobox”)  in ARIA 1.2. ARIA 1.1 combobox role implementation pattern is going to be no longer valid once ARIA 1.2 becomes W3C recommendation as the support of ARIA 1.1 combobox role implementation pattern is not very great. ARIA 1.2 combobox implementation pattern talks more or less ARIA 1.0 combobox implementation with aria-controls instead of aria-owns.

 

Aria-disabled(state)

Aria-disabled attribute is not going to be global attribute any more and it is allowed only in the certain roles

 

Aria-invalid(state)

Aria-invalid attribute is not going to be global attribute anymore and it is allowed only in the certain roles. The value of aria-invalid is also going to be enumerated type and it means that aria-invalid accepts certain list of token values

 

Aria-errormessage(property)

Aria-errormesage attribute is not going to be global attribute anymore and it is allowed only in the certain roles.

 

Aria-haspopup(property)

Aria-haspopup attribute is not going to be global attribute anymore and it is allowed only in the certain roles.

 

Aria-expanded(state)

There are significant changes to aria-expanded attribute in terms of which role should allow and which role should not. Aria-expanded attribute is going to be allowed in the menuitem role, checkbox role and application role. In addition, aria-expanded attribute is not going to be allowed on many roles(such as alert, alert dialog, article, main, banner, contentinfo, and so on.)

 

Listbox(role)

Group role has been added as child of listbox role

 

The role(s) that is probably going to be deprecated

Directory

Directory role is going to be deprecated

 

Minor changes that are probably going to take place on the existing roles and attributes

• The below roles are not going to have any default value(aria-checked)
  • Checkbox
  • Menuitemcheckbox
  • Menuitemradio
  • Switch

 

• Checkbox role is going to support aria-required property
• List role is not going to allow group role as it’s children
• Row role in the context of treegrid is going to allow aria-positionset and aria-setsize attributes
• Math role is going to allow children
• Grid role is not going to allow aria-level as it’s supported attribute
• Aria-valuemin and aria-valuemax are going to supported attributes for the below roles instead of required attributes
  • Separator
  • Slider
  • Scrollbar
• Aria-orientation is going to be supported attribute for the scrollbar role instead of required attribute
• The default value of aria-valuenow attribute for the spinbutton role is going to be 0
• Spin button role is going to support aria-valuetext attribute
• Default value of the aria-valuemin and aria-valuemax for spinbutton role is not going to be present
• Certain roles(such as log, timer, and so on.) are not going to require accessible name

 

 

Editorial changes that are probably going to take place on the below roles and attributes

 

• Alertdialog role
• Alert role
• Rowheader

 

Do you have a feedback on these proposed changes?

ARIA WG opened ARIA 1.2 for the public review around couple of months ago and feedback can be submitted in the W3C ARIA GitHub repository or can be emailed to public-aria@w3.org. ARIA 1.2 is probably going to be come candidate recommendation(CR) in a month or so. Later this year, hoping that it is going to be become W3C recommendation too

References

• Aria1.2 specification: change log
• ARIA 1.2 milestone GitHub

 

Overview

ARIA 1.2 main goal is to add certain new roles and update the existing attributes and roles usage based on the feedback that ARIA WG received. In addition, New terminologies like prohibited states and prohibited properties have been introduced. Prohibited states and prohibited properties are nothing but those attributes are not allowed for the certain roles. To give an example, paragraph role(which is new role in the ARIA 1.2) does not allow aria-label and aria-labelledby attributes and this means that authors must not use aria-label and aria-labelledby role on the paragraph role. ARIA 1.2 specification is currently in the draft stage and This means that ARIA 1.2 specification may subject to change based on the feedback. ARIA WG opened ARIA 1.2 for the public review around couple of months ago and feedback can be submitted in the W3C ARIA GitHub repository or can be emailed to public-aria@w3.org. ARIA 1.2 is probably going to be come candidate recommendation(CR) in a month or so. Later this year, hoping that it is going to be become W3C recommendation too. A big kudos to ARIA working group for working so hard for the evolution of ARIA and making the web better place for everyone!

 

New roles that are probably going to come in the ARIA 1.2

 

There are bunch of new roles that are probably going to come in the ARIA 1.2 and let us look into them one by one briefly. of Course, we will discuss them one by one in detail in the future once ARIA 1.2 becomes W3C recommendation

Blockquote

Blockquote role(role=”blockquote”) is related to HTML <blockquote> tag and authors can use this role on content that is quoted from the different source.

 

Caption

Caption role(role=”caption”) is related to HTML <caption> tag and HTML <figcaption> tag and authors can use this role to name/describe the table, grid, and figure. Caption role prohibits aria-label and aria-labelled by attributes.

 

Code

Code role(role=”code”) is related to HTML <code> tag and authors can use this role on the container that has the piece of the computer code. When assistive technologies like screen reader detects code role then screen readers are supposed to read all the punctuations. Code role prohibits aria-label and aria-labelled by attributes.

 

Deletion

Deletion role(role=”deletion”) is related to HTML <del> tag and authors can use this role either on the content that has been deleted or on the content that has been recommended for the deletion. Deletion role prohibits aria-label and aria-labelled by attributes.

 

Insertion

Insertion role(role=”insertion”) is related to HTML <ins> tag and authors can use this role either on the content that has been inserted into the document or on the content that has been recommended for the insertion. Insertion role prohibits aria-label and aria-labelled by attributes.

 

Meter

Meter role(role=”meter”) is related to HTML <meter> tag and authors can use this role on the element that has the scalar measurement within the known range or fractional value. Meter role and progressbar role cannot be used interchangeably and both are for the different purposes.

 

Paragraph

Paragraph role(role=”paragraph”) is related to HTML <p> tag and author can use this role on the content that is paragraph. Paragraph role prohibits aria-label and aria-labelled by attributes.

 

Subscript

Subscript role(role=”subscript”) is related to HTML <sub> tag and authors can use this role for the any meaningful text(not for the presentation purpose) that appears half a character below the normal line. Subscript role can be used for the chemical formulas like o2(oxygen). Subscript role prohibits aria-label and aria-labelled by attributes.

 

Superscript

Superscript(role=”superscript”) role is related to HTML <sup> tag and authors can use this role for the any meaningful text(not for the presentation purpose) that appears half a character above the normal line. Superscript role can be used for the footnotes. Superscript role prohibits aria-label and aria-labelled by attributes.

 

Time

Time role(role=”time”) is related to HTML <time> tag and authors can use this role on the content that represents the time/date.

 

Emphasis

Emphasis role(role=”emphasis”) is related to HTML <em> tag and authors can use this role on the any meaningful text(not for the presentation purpose) that is emphasized, but not on the text that is conveying importance. Emphasis role prohibits aria-label and aria-labelled by attributes.

 

Strong

Strong role(role=”strong”) is related to HTML <strong> tag and authors can use this role on the any meaningful text(not just for the presentation purpose)  that conveys importance/urgency/seriousness , but not on the text that is emphasized. Strong role prohibits aria-label and aria-labelled by attributes.

 

Generic

Generic role(role=”generic”) is related to HTML <div> tag and HTML <span> tag and this role is for the implementers of user agents but not for the authors. Implementers of user agents pass the generic role for those containers that do not have name and that do not have semantics to prevent the accessibility tree structure from the malware. Generic role prohibits aria-label and aria-labelled by attributes.

Just wait and take little bit break!

This is the series of the blog post and we pretty much covered the new roles that are probably going to come in ARIA 1.2 in this part1 blog post. To know what changes that are probably going to take place on the existing attributes and roles usage, head on to  part2(What’s probably coming in the ARIA 1.2?_part2)blog post

 

References

• Aria1.2 specification: change log
• ARIA 1.2 milestone GitHub

 

Description

We discussed about live regions(aria-live) in the past and this post also related to the live region itself. Before we understand aria-atomic, let me just recap what is the live region all about. When parts or portion of the web page gets updated without reloading the entire page and that portion of page is set to aria-live then those areas are called as live regions. To simplify further, whatever the changes that are happening to the element/container that has aria-live with appropriate token values(assertive/polite) are going to be communicated/notified to the screen reader users. However, here is the tricky thing. The underlying fact with aria-live with assertive/polite token values is that aria-live just notifies changes alone, but not the entire content that is present in the live region. You might be thinking that What is the big deal if entire content in the live region is not communicated to the screen reader users. Let me explain this with simple example. I think most of us do shopping on the ecommerce website for one or other things these days. While doing shopping on the ecommerce site, it is common that, whatever the products that we like, we add to the cart. As soon as the product gets added to the cart, it is obvious for the visual users that product has been added to the cart. To communicate the same to the screen reader users, we set aria-live to assertive/polite for the dynamic container. Do you think aria-live alone with assertive/polite is going to solve the purpose? Answer is not to the full extent. The reason is that the changed content of the dynamic container is going to be communicated to the screen reader users when live region is set but entire  content in the dynamic container is not going to be communicated. This may create some problems for the users in understanding the live updates. Let us understand what problem we are going to face. When product gets added to the cart then screen readers notify the live updates like “1” or “2” or “3” or something like that. Do you think this type of notification is understandable? Answer is no. to make same notification understandable, screen reader should reread the entire content in the live region live “your basket contains 1” or “your basket contains 2” or “your basket contains 3” or something like that. To reread the entire content in the live region as and when user activates add to cart, aria-live alone is not going to help, and this is kind of problem.

To address this problem, aria introduces aria-atomic attribute. Aria-atomic indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute(We will discuss about aria-relevant attribute in the future blog posts). To put this  simpler, when aria-atomic is set to true for the same shopping cart live region and product gets added to the cart then screen readers reread the entire content like “your basket contains 1” or “your basket contains 2” or something like that. This kind of announcement is pretty much understandable instead of just announcing like “1” or “2” when user activates add to cart element. Aria-atomic attribute accepts 2 values and they are true and false.

Author notes

• Aria-live can be used on any base markup and it is the global attribute
• The default value of aria-atomic is false for all elements
• Authors need to set the value of aria-atomic as true only  when the entire content in the live region along with the label of the live region(if exists) needs to be reread by assistive technologies.
• If author sets explicitly aria-atomic as false, then assistive technologies stop searching up ancestor chain and present the changed node to the user
• If author does not set aria-atomic attribute itself in the live region then assistive technologies, consider the default value of aria-atomic as false and present the changed node to the user.

Sample code snippet

<h2>Basket summary</h2>

<div aria-live=”assertive” aria-atomic=”true”>

    <p>Your basket contains <span id=”quantity”>0</span> items.</p>

</div>

References

• WAI ARIA1.1 specification: aria-atomic(property)

Description

In this modern web, it is very common to have dynamic updates/changes on the web. If you are wondering what the dynamic changes on the web is then here is the explanation. Dynamic changes are nothing, but the parts or portion of the web page gets updated without reloading the entire page and it is as simple as that. The examples could be chat log, stock ticker, cricket score board, ticket’s price list, search result on the fly, and so on. That said, When the dynamic changes/updates take place on the web then it is visually apparent that something is going on. However, same may or may not be communicated to the screen reader users as screen reader users can interact with only one part of the page at a time and they may not aware of the changes that are taking place at the other part of the page. If the update about the changes is not communicated/notified to the assistive technology users, then it is going to be nightmare for the users. It is important that authors need to communicate/notify these changes to screen reader users to make sure that users of screen reader are not lost on the web page.

ARIA introduces aria-live attribute or live roles to communicate/notify these dynamic changes to the screen reader users without moving their focus. Let us discuss more about aria-live in this post. Aria-live Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region. To put it simpler, as soon as we set aria-live on any HTML container, the HTML container becomes live region. whatever the changes that are taking place in this container, assistive technologies will notify those changes to the users based on the value of the aria-live that we have set. The value of aria-live attribute is token and it accepts 3 values. The accepted values of aria-live are assertive, polite, and off, and will discuss in-details of purpose of all these values in the author notes section of this post.

Author notes

• Aria-live can be used on any base markup and it is the global attribute
• The default value of aria-live is off for all elements
• Authors need to set the value of aria-live as assertive(aria-live=”assertive”) only if the updates are critical(like user name and password are incorrect). The reason is that assertive value interrupts the user’s current task and notify the updates immediately
• Authors need to set the value of aria-live as polite(aria-live=”polite”) only if the updates need to be notified by assistive technology at the next graceful opportunity. The reason is that polite value does not interrupts the user’s current task and notify the updates at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing.
• Authors need to set the value of aria-live as off(aria-live=”off”) when the updates need not to be notified to the assistive technology users
• Authors sometimes use hidden live regions to notify the important updates to the screen reader users. It is important to remember that these hidden live regions must be removed from the DOM as soon as the purpose is accomplished. Failing to do so results the screen readers to read the same live region content in the browse mode/reading mode without any context and this creates confusion to the users like why that text is present and so on.
• if multiple changes to a live region should be spoken as a single unit of speech then follow the below steps
  • apply aria-busy at the start of updates to the region
  • perform necessary updates
  • remove aria-busy (or set to false) at the end of updates
• For robust support, it is advised to include aria-live always in the initial markup itself but do not add the aria-live container dynamically with the script. Even author wants to add aria-live container dynamically to the DOM with the script(better to avoid this approach as much as possible), it is important to maintain some time delay to insert the dynamic message in the dynamic container for screen readers to pick this dynamic message.

  Do not do this:

  <div class=”will-change”>

    <!—both live container and content within the live container will be updated with Javascript –>

  </div>

  <script>

  document.querySelector(“.will-change”).setAttribute(“aria-live”, “polite”);

  document.querySelector(“.will-change”).textContent = “New content!”;

  </script>

  Instead, Do this:

  <div aria-live=”polite” class=”will-change”>

      <!– content will be updated with Javascript –>

  </div>

  <script>

  document.querySelector(“.will-change”).textContent = “New content!”;

  </script>

Sample code snippet

Here are sample code snippets for all the 3 different values

<h1>Polite</h1>

<button onclick=”updateContent(‘msg’)”>To view the updates, click this button!</button>

<br/> <br/>

<div id=”msg” role=”region” aria-live=”polite” id=”msg”></div>

<h1>Assertive</h1>

<button onclick=”updateContent(‘msg2’)”>To view the updates immediately, click this button!</button>

<br/> <br/>

<div id=”msg2″ role=”region” aria-live=”assertive”  id=”msg”></div>

<h1>Off</h1>

<button onclick=”updateContent(‘msg3’)”>No updates will be announced, so don’t click this button 😂!</button>

<br/> <br/>

<div id=”msg3″ role=”region” aria-live=”off” id=”msg”></div>

Complementary info on aria-live

authors sometimes use CSS attributes(from display:none to display:block and vice-versa) to show and hide the dynamic message in the live container in order to notify the message to the screen reader users. However, this may not work as expected in some of the screen readers. It is better to use script to inject the dynamic message in the aria-live container in order to get robust support in most of the screen readers.

References

WAI ARIA1.1 specification: aria-live(property)

Description

In this modern web, it is very quite common to have dynamic updates/changes on the web. If you are wondering what the dynamic changes on the web is then here is the explanation. Dynamic changes are nothing, but the parts or portion of the web page gets updated without reloading the entire page and it is as simple as that. The examples could be chat log, stock ticker, cricket score board, and so on. That said, When the dynamic changes/updates take place on the web then it is visually apparent that something is going on. However, same may or may not be communicated to the screen reader users. If the update about the changes is not communicated to the assistive technology users, then it is going to be nightmare for the users. During the dynamic changes, one can observe 2 steps. The first one is that web application or web page communicates to the user that it is currently busy with the help of some animations (such as spinner, loading, and other indicators) before actual changes take place on the web page. Basically, it indicates that we should not interact with the web page while update process is going on and need to wait till the update process is completed on the page. The second step is that actual changes display on the web page once the update process is completed. It is important that authors need to communicate these 2 steps to screen reader users to make sure that users of screen reader are not lost on the web page

ARIA introduces aria-busy attribute and aria-live attribute or live roles to communicate step1 and step2 respectively that is mentioned above. Let us discuss more about aria-busy in this post. Aria-busy Indicates an element is being modified and that assistive technologies MAY want to wait until the modifications are complete before exposing them to the user. Aria-busy accepts 2 values and they are true and false. The default value of aria-busy is false for all elements. When aria-busy set to true for any element then it indicates that the element is being modified/updated.

Author notes

• Aria-busy can be used on any base markup and it is the global attribute
• The default value of aria-busy is false for all elements
• When aria-busy set to true for any element then
  • screen readers are not supposed to expose any of the content which is inside of that element
  • It will be good if screen readers announce “busy” audibly when that element receives the focus
• if multiple changes to a live region should be spoken as a single unit of speech then follow the below steps
  • apply aria-busy at the start of updates to the region
  • perform necessary updates
  • remove aria-busy (or set to false) at the end of updates
• authors must set aria-busy to true until and unless all the children of the widget are loaded if the dynamic widget (live region) has any children

Sample code snippet

<div aria-live=”polite” aria-atomic=”true” aria-busy=”true”>

  <span>Total: $400</span>

</div>

Complementary info on aria-busy

As discussed in the author notes section of this post, screen readers should not expose any of the content that is inside of the element that has aria-busy set to true. Except JAWS, however, rest of all other screen readers exposes the content that is inside of the element that has aria-busy set to true. Similarly, as of now, no screen readers announce busy state audibly when element that has aria-busy set to true receives the focus.

References

• aria1.1 specification: aria-busy(state)

Description

Tooltip is a small bubble that appears when hover over or focus on the element and it provides the contextual information of the triggering element. To give you a simple example, we sometimes see question mark (help) icons beside the elements on the web. When we hover over or focus on this question mark icon then it displays the contextual information of that particular element. Now the question is that how to make these tooltips accessible to people with disabilities. Let us look into that. Authors tend to use HTML title attribute to display the tooltip as title attribute belongs to the native HTML but it is not suggested though. The reason is that the HTML title attribute is not well supported in the cross browser platforms, especially mobile/touch phones. Even though HTML title attribute belongs to the native HTML, it is the fact that support of the title attribute is not so great. Thus, the option of using HTML title attribute to display the tooltip is not encouraged. Instead of using HTML title attribute, Authors must use different techniques (such as scripts, CSS, and so on…) to display the tooltip. While constructing the tooltips with the different techniques, authors need to make sure that tooltip gets displayed even on focus along with the on hover. When authors follow this on focus pattern along with on hover pattern then the tooltip is going to be accessible to keyboard users. Now the question is that, if the tooltip is accessible to the keyboard users then do you think tooltip is going to be accessible to the screen reader users as well automatically?  Answer is no. There are some additional efforts authors need to put in order to make the tooltips accessible to the screen reader users. Let us look into that.

It is pretty simple to make the tooltips accessible to screen reader users. The solution is ARIA. Authors need to use just ARIA tooltip role to make the tooltips accessible to the screen reader users. To know how to use/implement ARIA tooltip role, please follow author’s notes section in this article. It is important to note that tooltip semantics/role would not be communicated to the users by most of the screen readers in spite of tooltip role is applied to the appropriate container. Not announcing the tooltip semantics/role is absolutely fine as long as tooltip information is conveyed with short delay or no delay to the users. Authors also need to remember that tooltips content should be short and sweet! The main reason for asking the tooltips content to be shorter is that screen reader announces the complete tooltip information at a time to the users and there is no provision for the users to navigate the tooltip content character by character/word by word/line by line and so on… when the tooltip is constructed as per the ARIA specification. With this restriction, screen reader users would not be able to comprehend the content very easily if the tooltip content is so longer unless user listens to the content again and again from the beginning. Thus, the request for the authors is that keep the tooltip content as short as possible.

There is common misconception that tooltip and non-modal dialog are one and the same but they are different. Typically, tooltips would not have any focusable elements whereas non-modal dialog would have focusable elements.

Author notes

• Tooltip role must be set on the element that serves as the tooltip container.
• aria-describedby must be set on the element that triggers the tooltip and it references the tooltip element
• Tooltip widgets should not receive focus and A hover that contains focusable elements must be made using a non-modal dialog
• Focus must stay on the triggering element while the tooltip is displayed
• The tooltip widget must be shown via both on focus and hon hover
• The tooltip widget must be hidden by removing focus from the element or by moving the mouse off the element
• The tooltip widget should be hidden by pressing the Escape key
• tooltip should not be disappeared while it’s being hovered

Sample code snippet

<div class=”ttipcontainer”>

  <button  class=”co_tooltipElement” id=”newButton05-2″ aria-describedby=”coid_accessibleTooltip_1″> Recent Searches </button>

  <span tabindex=”-1″ class=”co_accessibilityLabel” id=”coid_accessibleTooltip_1″ aria-hidden=”true” role=”tooltip”>Shows information of your recent searches</span>

</div>

Reference’s

• APG: Tooltip(work in progress)
• Tooltips and toggle tips by Heydon works
• Oaa tooltip example
• Practical ARIA examples by Heydon
• JQuery accessible simple tooltip, using ARIA

There is nothing wrong using ARIA to remediate/fix the accessibility issues as long as the authors have thorough knowledge on how and when to use ARIA. At the same time, we need to remember that misuse of ARIA damages the accessibility much more than not having ARIA. There is a saying like no ARIA is better than bad ARIA. This blog post attempts to highlight some of the common mistakes that author does while remediating the accessibility issues with the help of ARIA.

WAI-ARIA mistake #01: Incorrect WAI-ARIA syntax

As you know, most technologies require a certain syntax in order for things to work as expected. Similarly, WAI-ARIA also requires a certain syntax in order for things to work the way they’re supposed to. Failing to provide the correct syntax can lead to unexpected results. Let’s discuss some of the common syntax errors that author introduce in their code, and result in assistive technologies not working as expected.

• Role values are assumed to be case insensitive: Role values define the purpose of objects in the page. Authors often fail to implement these values following the lowercase convention established by the WAI-ARIA specification. For example, role=”LINK” can be provided, with the value types in as uppercase letters and as a result, assistive technologies cannot identify the object as a link. Authors need to remember that role values are case sensitive, and need to be typed in lowercase.
• Incorrect spelling for attributes or values: Attributes are often spelled incorrectly. For example, aria-label might be spelled out as aria-lable. As a result, screen readers fail to announce the accessible name of the control. Authors need to be mindful and make sure attributes are spelled correctly.
• Incorrect or invalid role declarations: Authors sometimes declare roles incorrectly. For example, role=”alert” might be declared as aria-role=”alert”. As a result, screen readers will fail to announce the live message. Authors need to avoid such mistakes and make sure to declare the roles appropriately using role=””, and not aria-role=””.
• Role do not exist or are invalid: Authors sometimes provide a role that does not exist according to the WAI-ARIA specification, somehow thinking it will still work, or will serve the same purpose. For example, authors might provide role=”error” for the error message in an attempt to convey the error semantics, but there is no such thing as role=”error” in the specification. Authors should become very familiar with the allowed role values to avoid such issues.

WAI-ARIA mistake #02: Children roles without parent roles

                Authors frequently define children roles on objects without first defining their parent role. As you may or may not know, certain roles cannot be used without their related parent/context roles. For example, a tab role might be defined without its tablist parent role. As a result, screen              readers may not work as expected. Some screen reader and browser combinations will still provide the information as expected, but others won’t, making it a very unreliable solution. Authors need to make sure that children roles are provided with their contextual or related parent roles.

WAI-ARIA mistake #03: Parent roles without children roles

Similarly, many times we see authors provide a parent role without defining the expected related children roles. As you may or may not know from the specification, certain roles cannot be defined without also defining their related children roles. For example, when menu or menubar roles are defined without the expected menuitem children roles for related objects, screen readers may not be able to convey the relationship as expected. Again, some screen reader and browser combinations will still provide the information as expected, but others won’t, making it a very unreliable solution. Authors need to make sure that parent roles are provided with their contextual or related children roles.

WAI-ARIA mistake #04: Invalid ID value references

We frequently see authors providing incorrect or inaccurate ID reference values for certain attributes. As you may or may not know, attributes are set to only accept ID references as their respective values, such as the aria-labelledby, aria-describedby, and aria-errormessage attributes. If authors provide an incorrect ID value, or assign an ID that does not exist in the document, then screen readers will not be able to create the reference and announce the information as expected (ex: the element’s label, the related instructions, the error message, etc). To avoid these situations, authors need to make sure that the ID values that are defined for WAI-ARIA attributes are valid.

WAI-ARIA mistake #05: Allowed WAI-ARIA attributes missing

We often see authors use WAI-ARIA attributes in ways that go against what is defined in the specification, hoping to make things better for accessibility. As you may or may not know, certain roles only allow for certain attributes. As an example, authors might assign aria-selected=”true” to the anchor/link element, falsely thinking that screen readers will announce the selected state of the anchor/link. However, since aria-selected is not allowed on link elements as per the WAI-ARIA spec, screen readers will NOT announce the selected state of such an element. On the other hand, when aria-selected attributes are used with certain roles such as treeitem, tab, gridcell and so on, it can work really well. Authors need to make sure that the attributes they assign to particular roles are allowed for those roles.

WAI-ARIA mistake #06: Required WAI-ARIA attributes missing

We sometimes see authors define WAI-ARIA roles without defining their expected required attributes. As you may or may not know, certain WAI-ARIA roles cannot be defined without also defining their expected required attributes. For example, when the slider role is defined on an object, certain attributes such as aria-valuemin, aria-valuemax and aria-valuenow must also be defined. Failing to do so results in screen readers not conveying the information as expected. Therefore, authors need to make sure they provide all expected required roles and attributes when a particular WAI-ARIA role is used.

Oh, wait! I have a quick tip

If you are wondering how to catch all these 6 mistakes then use Deque axe  tool. Yes, AXE catches all of the 6 mistakes that we have discussed in this blog post. You just need to run the AXE tool and that is all, it throws the issues!

References

• WAI ARIA 1.1 specification

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

• ARIA 1.1: combobox role
• WAI  ARIA  1.1 authoring practices: combobox with listbox popup example
• WAI ARIA  1.1 authoring practices: combobox with grid popup example
• ARIA 1.0 Combobox with Both List and Inline Autocomplete example
• ARIA 1.0 Combobox with List Autocomplete example
• ARIA 1.0 Combobox Without Autocomplete example