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>


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.


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 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 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.


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.


Tooltip role


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>



WAI ARIA: few mistakes to avoid

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!


Combobox role


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”>


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

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

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


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.


WAI ARIA global attributes


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>


Rules of ARIA


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


None role


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>


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


My AHG2018 experience

What the heck is AHG conference all about?

Early this year, I spoke in the CSUN international conference. Later this year, I got another opportunity to speak in the international conference, and it was accessing higher ground conference. The Short form of accessing higher ground is AHG. AHG focuses on the implementation and benefits of: accessible media, Inclusive Design, accessible curriculum, and Assistive Technology in the university, business and public setting, read more about AHG here. AHG takes places every year and this year(2018) conference has taken place from 12th November to 16th November at Westin, Westminster Colorado, USA. The first 2 days of the conference usually go with some workshops/trainings and the next 3 days of the conference usually go with some technical sessions.

A little about how did my session go

I have travelled all the way from India for this conference to present the ARIA 1.1 topic and my topic name was WAI ARIA 1.1: an in depth view into new and shiny. First of all, I want to thank my employer(Deque) for giving such a wonderful opportunity.  As per the schedule, I spoke on my topic on 15th November at 8am. Although few technical glitches at the beginning, the session went well but there were less number of participants. Even though participants were less, there were more number of questions at the end, and I am glad I could answer most of the queries! In fact, there were healthy debates too!


what did I learn?

In my view, attending the conference is kind of mutual benefit for the both parties and it is beauty of the conference! We get the opportunity to learn what others are talking, and we also get the opportunity to share our knowledge with the big crowd. With that said, lot of educational institutions such as universities and colleges participated in this conference. Of course, few non-education institutions also participated here.  People in the conference were talking on the various topics such as document accessibility, multimedia accessibility, web accessibility, classroom accessibility, math accessibility, building the accessible course/curriculum/educational material, EPUB adoptions, software accessibility like Zoom, MS word, MS power point, UDL adoptions, , different assistive technologies, and so on. I heard more on document accessibility though as this conference was more of educational related platform.

As mentioned earlier, 3 days of the conference usually go with lot of technical sessions. I have looked at 3 days schedule and chosen some of the sessions to attend. I attended the sessions that were relevant to web accessibility and the sessions that could help me to become independent at my work.  Below are some of the sessions that I attended along with my learnings

Session name: Making Websites Usable, Not Just Accessible


This session was presented by Karen Hawkins, Senior Experience Designer, Publicis.Sapient. it went for 2 hours long. The interesting thing in this session was that she explained how the end user pain would be while browsing the ecommerce website although it was accessible site. She highlighted possible usability issues such as clumsy filters, not notifying the changes to the screen reader users, and so on.. in the ecommerce website. She highlighted the usability issues starting from product landing page till placing the order. At the end, she mentioned that they would be releasing accessible and usable ecommerce templet in the mid of the next year. They said that this new templet would help everyone who would like to make their ecommerce website accessible and usable and that was very exciting thing! Looking forward to see the great ecommerce templet from these people!


Session name: How to CADET: free caption and audio description authoring software from WGBH’s NCAM


This session was presented by Bryan Gould, Director , WGBH/NCAM. He explained how easy to add/edit  the captions and audio descriptions scripts with the help of their CADET  tool. CADET  tool  is free and downloadable software. In addition, they said that the interface of this tool would be very much accessible unlike other tools in the market.


Session name: What is VPAT® 2.0?

This session was presented by Joe Humbert, Senior Accessibility Analyst, Interactive Accessibility. The funny thing was, by the time this session was scheduled, VPAT 2.2 had been released too! He mentioned about that fact at the beginning of his session. He highlighted the one of the major changes from VPAT 2.0 to VPAT 2.2 was that there would not be “supports with exceptions” status in 2.2 and it got changed to “partially supports”. He explained majorly the difference between from 1.0 to 2.0 in this session. At the end, when he opened for the questions then we all of us were asking when WCAG2.1 would be incorporated in the VPAT. Immediately, we got the response from the women who sat behind and introducing herself that “I am from ITI and works for the VPAT”. Everybody got shocked and surprised! She responded that they started working on incorporating the WCAG2.1 in the VPAT and would release the next version in few months. By the way, ITI is the organization who develops the VPAT. Anyways, I have got opportunity to meet such a great person with the help of this session.

A quick tour on the booths/exhibitors

As like any other conferences, there were number of booths in this conference too. I think there were more than 30 booths here. As usual, all the booths were showcasing about their products and services. While I was visiting this booths, I found some interesting stuff. One of the interesting things was that many organizations were working in the PDF remediation space. In fact, some of the organizations(such as Onix-equidox, Appligent Document Solutions, Commonlook, Crawford Technologies, Pubcom, and so on..) developed their own PDF remediation tools too. I felt that Equidox PDF remediation tool by Onix was bit interesting with the advanced features that has! Apart from that, I have got opportunity to look at the other web accessibility tools such as Compliance Sheriff by a Cyxtera solution,  Blackboard Ally, Dinolytics, and so on.. overall, I felt worth time spending on this booths.



 How did I feel about the conference as a whole?

I felt that conference was very cool going. I like the way the technical sessions on those 3 days were scheduled. There were No back to back technical sessions and we used to have some breakout meetings once in every 2 hours. Breakout meetings/sessions such as round table and lunch breakouts were the another thing I wanted to highlight. These breakout sessions gave an opportunity to meet and talk to the various people and that was fantastic! Another cool thing was that audiences got an opportunity to rate the sessions that they attended. In fact, my session was rated 4.1 stars average rating out of 5 stars and I was very happy for that!


Oh, wait! I know your next question

Probably, your next question is going to be where I can access and download all these great AHG presentations. Here are the simple steps to download any AHG presentation

  1. Open AHG schedule
  2. It shows Wednesday schedule by default. You can view Thursday and Friday schedules by clicking on the corresponding links on the same web page
  3. Choose any topic that is relevant for you and activate the link
  4. It opens the session information with summary, speakers, abstract, handouts, and so on..
  5. Navigate to the handout section and activate the link
  6. That is all and presentation/ppt/deck/PDF  is going to be downloaded for that topic

Thank you and will be back again!


ARIA 1.1 overview


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.



The following attributes have been deprecated in aria1.1

  1. aria-dropeffect
  2. aria-grabbed



  1. aria1.1 specification: c. change log