aria-atomic(property)

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

aria-live(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)

aria-busy(state)

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

Inclusive design, Accessibility, and Usability

The terms inclusive design, accessibility, and usability are being used interchangeably by most of us. Although the purpose of those 3 terms are kind of similar (accommodating the web to as many as users), however, they are slightly different from each other in terms of it’s meaning. This blog post attempts to give you the basic understanding of these 3 terms. Let us look into them one by one

Inclusive design

Inclusive design is nothing but no one should be excluded in using product and it talks about people first as well as design for all. Let me explain this with simple examples. If I am giving the lecture in the Spanish language to the group of people and some of the group members do not know the Spanish language, then my lecture is not an inclusive. The reason for not being inclusive is that the group members who do not know Spanish language are completely excluded from the other group members due to the language barrier, which is not really great thing. To make the environment inclusive, we need to figure out what is the common language among all of them (perhaps English) and start giving the lecture as accordingly. Similarly, another example could be manufacturing the chairs. During the initial stages of chair development itself, manufactures should think through different personas who uses the chair. The different personas in this context could be, is my chair usable for tall person, is my chair usable for short person, and so on. if the manufacturer does not thing through different type of end users who use chair during the initial stages itself then it is high chance that chair is not going to be usable to certain group, which is not inclusive. These are the simple examples that I provided to make you understand what is inclusive. We can apply the same concept anywhere starting from designing the physical products to the designing the web and so on.

To put the things simpler, Inclusive design targets/aims to accommodate the web to the full range of human diversity. When we say diverse users then the design of the product should be in such a way that it can be used by different people such as people with different culture, people with different geographical location, people with different computer literacy and skills, people with low internet connectivity, people who speaks different languages, people with different education background, people with the different age group, people with disabilities, and so on.. thus, inclusive design does not talk accessibility of people with disabilities alone and it talks much more than just accessibility of people with disabilities. Accessibility of people with disabilities is just one single part of the inclusive design. On other hand, most of the designers forget to consider people with disabilities group all together during designing phase. Forgetting to consider people with disabilities group during design phase may not be an intentional thing but many designers may not aware of that there is such a group exist. Sometimes, forgetting to consider the people with disabilities group during design phase may be an intentional thing because designers/company thing that people with disabilities are minority only. When they think so then implication is so huge as you are leaving 15 to 20% of the world population. Yes, as per the recent census, 15 to 20% of the world population has one or other form of disability. Whatever the reason it could be, you are leaving 15 to 20% of world population in accessing your product if you do not consider the people with disabilities group. Therefore, as part of the design process, designers should consider the different personas including people with disabilities in order to make the design as inclusive as possible. On top of that, when accessibility is being considered at the design phase itself then it is going to reduce your time, money, and effort. In fact, we preach accessibility should be considered at the requirement phase itself and that would result much more inclusive experience.

There is one more term called universal design, and this is almost identical to the inclusive design. It is ok to use either of the terms based on the contexts.

Accessibility

Accessibility talks about addressing the challenges of people with disabilities in general whereas web accessibility talks about addressing the challenges of people with disabilities to the web specific. Inclusive design is the process/method of the making the products/services to the diverse users whereas web accessibility is the result of the inclusive design process. web accessibility means that people with disabilities can equally perceive, navigate, operate, and understand the websites and tools. Web accessibility also talks about more of principles, standards, guidelines, checkpoints, techniques, and so on. and it is kind of the measurement how accessible the product/service/web is for people with disabilities. On other hand, inclusive design talks about more of abilities of the different type of the users, frustration of the different type of the users, challenges of the different types of the users, and so on.

Apart from that, Web enhances it’s usability when the site is accessible. Let me explain this with examples. When the accessibility color contrast guideline is followed then it is not only helping low vision users but also it helps even sighted users who use the device in the sunny. Another example providing the captions for the videos/multimedia. As per the accessibility requirement, captions are needed for all the videos/multimedia in order to help people with hearing impaired. Providing the captions for the videos/multimedia just not only helps the people who are hearing impaired but also helps the hearing people when the videos are opened in the noisy environment. Thus, some of the accessibility requirements enhances the usability for all.

In addition, Web enhances the inclusion aspect as well when the site is accessible. Let us look into that with the examples. Providing the alt text for the informative images is the accessibility requirement in order to help screen reader users. Text alternative for the informative images not only helps the screen reader users but also helps the people who are having connectivity issues. Another example could be making the web content as understandable as possible with all relationships. Simple design and easy language not only help the people with disabilities but also the people with low literacy or not fluent in the language/people who are new users or infrequent users. Thus, some of the accessibility requirements improves the inclusion aspect as well.

Usability

Usability is about designing products to be effective, efficient, and satisfying and is the qualities that make a web experience intuitive and easy to use. To put it in the simple words, usability is nothing but how easy it is for the users to complete certain task on the web. For example, booking flight ticket in the airlines involves with multiple steps (such as searching for the flights, choosing the right flights, booking the seat, payment, and so on.)  and how easy user can navigate, understand, operate, and complete the desired task is all about the usability.

The sad part of the story is that most of the times people with disabilities are not considered in the usability process and this is forgotten. It is important that real people with disabilities along with other users are involved in the usability process to make the web usable to all. In addition, the real people with disabilities should be involved from the design phase to all the stages of the product development and that leads to usable accessibility. Usable accessibility is nothing, but web is usable and accessible for all the users including people with disabilities.

 Conclusion

Inclusive design is the process/method to accommodate the web for diverse users including people with disabilities. Web accessibility talks about how well the people with disabilities can access the web and it is usually the result of the inclusive design process. Usability talks how easy it is for all the users including people with disabilities to accomplish certain task on the web. All 3 terms (inclusive design, accessibility, and usability) sound similar but they are slightly different from each other and all together makes the web better place for everybody.

References

Tooltip role

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