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





As discussed in aria-rowcount post, at time, author might not want to show all the total rows of the table in the DOM due to the usage of advance filters and so on rather author might want to show only portion of the rows in the DOM. When author wants to show only the portion of the rows of the table in the DOM then it is  suggested to use aria-rowcount property to communicate the total no of rows to the assistive technology users. Up to this, we are clear with the concept. However, using aria-rowcount alone would not be sufficient to convey all the table properties to the assistive technology users. Since only the portion of the rows are visible in the DOM, assistive technologies like screen readers do not understand which cell/row has the data. As a result, screen readers might end up with incorrect row index announcements when user navigates through the table and it is a problem.

In order to address this problem, aria1.1 introduced the new brand table property and that is aria-rowindex. When aria-rowindex property is set on the cell container of the table then screen readers would understand row index of that cell and announces the row index accordingly. Let me elaborate this little bit more. As we have been discussing, this property should be used only when the portion of the rows in the tables are available in the DOM. By considering this important point in the mind, let us think there are 4 rows(row2, row3, row5, and row9) of the table are available in the DOM out of 20 total rows. If aria-rowindex is set as 2 for the row2 cell then screen readers would announce the row2 and this announcement is appropriate. Failing to set this attribute may result the incorrect row index announcements by screen reader software and this intern confuses the users a lot. When aria-rowcount is set for the complete table container then it is necessary to set the aria-rowindex to define the position of the visible row of that table.

In a broader view, aria-rowindex Defines an element’s row index or position with respect to the total number of rows within a table, grid, or treegrid.


Author notes

  • Aria-rowindex property must be used for the below roles only
    • Cell
    • Row
    • Column header
    • Gridcell
    • Rowheader
  • Authors should not set/define this attribute If all of the rows are present in the DOM as user agent can automatically calculate the row index of each cell or gridcell
  • Authors should set/define this attribute only when portion of the rows is present in the DOM at a given moment
  • Aria-rowindex attribute is needed to provide an explicit indication of the row position
  • Authors MUST set the value for aria-rowindex to an integer greater than or equal to 1,
  • Aria-rowindex must be greater than the aria-rowindex value of any previous rows
  • Aria-rowindex must be less than or equal to the number of rows in the full table
  • aria-rowindex cannot be greater than aria-rowcount, unless aria-rowcount is unknown (e.g. value -1)
  • aria-rowindex must be set on the start of the span if the cell or gridcell spans multiple rows


Sample code snippet

if given

<div role=”table”>

<div role=”row”>

<div id=”sd” role=”cell” aria-rowindex=”5″>test</div>



Then expose aria-rowindex=”5″ on the element with id=”sd”





As you may be aware of, making the simple tables accessible is much easier than making the complex tables accessible. In my view, there is no problem with the complex tables as long as they are accessible to the assistive technology users. Usually, complex tables would have multi-level column headers/row headers and it is one type of variety but there are many more verities within this complex tables. We are not going to discuss all the varieties of the complex table rather will discuss how one single row header becomes the row header for multiple rows in this post. Let us understand this in-details. Usually, we see the pattern like one single row header would be present for entire row and basically it is called as simple data table. In case of complex table, multiple rows/entries may have the sane row header like sidebar. To understand what are the different rows that have common row header, visually, authors need to group the related rows technically(like all the related rows need to be grouped with the corresponding row header by merging the cells with the help of CSS paddings and HTML row span techniques. When they do so, it is semantical to both sighted and assistive technology users that how many cells are spanned or so. Since the context that I have made so far is all about native data table, the semantical information is conveyed to the assistive technology users. However, the information about how many rows are spanned would not be conveyed to the assistive technology users if it is custom table as custom table is built with <div> and <span> tags and with other CSS properties and it is a problem.

In order to address this problem, aria1.1 introduced new brand attribute and it is aria-rowspan. Aria-rowspan defines the number of rows spanned by a cell or gridcell. When aria-rowspan is defined for the cells in the custom table, assistive technologies like screen reader are expected to understand how many rows are spanned and are expected to convey the same information to the users. The information about how many rows are spanned in the table enables the screen reader users to visualize the table structure very clearly than ever before. as I have explained this concept with the spanning of row headers, it does not mean that spanning the rows is not limited to row headers. Author can span any rows by using aria-rowspan attribute based on the requirement.



Author notes


  • Author must use this attribute on the below roles only
    • Cell
    • Gridcell
    • Column header
    • Row header
  • Authors MUST set the value of aria-rowspan to an integer
    • greater than or equal to 0
    • less than value that prevents overlapping of other cells in the same column. In simple terms, if author wants to span 3 rows then the value of aria-rowspan must be set to 3 only but not to 4 or 5 or so.
  • Aria-rowspan=”0” means the cell spans all the remaining rows in its row group.


Notes for assistive technology venders

  • Assistive technologies should not expose the value of aria-rowspan for an element if equivalent host language attribute is provided rather assistive technologies should expose the value of the host language’s attribute.




Sample code snippet

<div role=”table”>

<div role=”row”>

<div id=”sd” role=”cell” aria-rowspan=”2″>test cell</div>



then expose aria-rowspan =”2″ on the element with id=”sd”





Even though the web is accessible, sometimes efficiency matters like how quicker the people with disabilities can perform the things on the web, especially frequent actions. Let us understand this better with the web email application as an example. There are many frequent actions in the web email application such as composing an email, sending an email, replying to an email, and so on.. author would have done those elements accessible but still navigating to those elements from the user’s current position on the web for such frequent actions would consume certain amount of time. It is always better to provide hot keys for the users to perform such frequent actions on the web in order to enhance the user’s efficiency in performing the things on the web. Hotkeys/keyboard shortcuts not only help the efficiency of the people with disabilities but also efficiency of the power users as power users take some time to locate the desired item with the mouse pointer. Web Gmail, for the instance, already implemented the hot keys(like C for compose, control enter from the message area to send the email, R for reply, and so on..) for such frequent actions. Do you think assigning and implementing the keyboard shortcuts happen just like that? Answer is no. first of all, there should be provision for author to add/define the keyboard shortcuts for an element programmatically and this provision is not present in ARIA till ARIA1.0, and it is a problem.

In order to address this problem ARIA1.1 introduced new attribute called aria-keyshortcuts. Aria-keyshortcuts Indicates keyboard shortcuts that an author has implemented to activate or give focus to an element. In other words, aria-keyshortcuts enables the author to define what keyboard shortcuts activates or takes the focus to an element. When aria-keyshortcuts attribute is defined for an element then assistive technologies like screen readers are expected to announce name of the element and it’s keyboard shortcut(for ex: compose button alt+c). to put it simpler, aria-keyshortcuts exposes the availability of the keyboard shortcut having said that, the functionality of the keyboard shortcut is completely dependent upon the web developer. Web developer needs to write the script for functioning the keyboard shortcut as expected. Author should choose the keyboard shortcut in such a way that keyboard shortcut must contain 0 or more modifier keys and exact one non-modifier key. If you are wondering that what modifier key means? Modifier key is nothing but alt, shift, control, and so on.. whereas non-modifier key is nothing but any printable character(a, b, 1, 2$, and so on..)

In addition, there is a misconception that both aria-keyshortcuts and HTML accesskey do the same thing but that is not true. Although they both do the similar kind of job like assigning/defining the keyboard shortcuts/hotkeys, the way of the implementation differs. The main difference between both of them is that, if HTML accesskey attribute is defined for an element then modifier key is decided by browser but if the aria-keyshortcuts attribute is defined for an element then modifier key is decided by the author(again, it’s author wish whether modifier key should be provided or not in the keyboard shortcut). Let us not dig more about what all HTML accesskey do in this post and let us continue to put our attention on aria-keyshortcuts attribute.


Author notes

  • Author can use this attribute on any element of the base markup
  • Author must ensure that the value of this attribute is string
    • string may contain more than one keyboard shortcuts with space-delimited
    • Each keyboard shortcut consists of one or more tokens delimited by the plus sign(ex: alt+shift+t)
  • Authors must ensure that the modifier key comes first and non-modifier key comes last as part of the keyboard shortcut(for ex: it should be “alt+c” but it should not be “c+alt”)
  • It is author responsibility to make the keyboard shortcut functional as expected with the help of java script or with the help of other relevant programming techniques
  • Authors must ensure that both upper and lower letter of the non-modifier key in the keyboard shortcut function the same
  • Authors should implement the keyboard shortcuts by keeping the below points in the mind
    • Keyboard shortcuts should not produce unintended results when they are activated as different languages have the different keyboards
    • It is always better to have the ASCII letters instead of other keys in the keyboard shortcuts to prevent the conflicts from the international keyboards as numbers characters and common punctuation often require modifiers in the international keyboards(for ex: German keyboard).
    • The keyboard shortcuts developed by author should not conflict with the keyboard shortcuts of assistive technology, user agent, and operating system
    • The keys defined in the shortcuts represent the physical keys pressed and not the actual characters generated(ex: the keys in the keyboard shortcut should be “shift+5” but should not be “%”)
  • Authors should expose the keyboard shortcuts for the sighted keyboard users too by using tooltip or other techniques

Sample code snippet

if given



<div id=”sd” tabindex=”0″ role=”button” aria-keyshortcuts=”alt+c”>compose



then the element with role=”button” and id=”sd” exposes aria-keyshortcuts=”alt+c”





Can you imagine a form without a text fields? I think answer is no. usually, there are number of text fields present on the form. we commonly see the text fields, such as first name, last name, date, email, phone number, and so on.., on the form. Out of all the text fields, few text fields, such as date, phone number, email and so on.., require the hint to fill the data. Let us take date as an example. date fields are ambiguous in nature if hint/format is not provided to fill the date. The reason is that each country follows certain date format. For an instance, USA follows MM/DD/YYYY whereas India follows DD/MM/YYYYY. Thus, it is important to have accepted format as a hint for the date text field in order to enable the user to fill the data appropriately. To provide such hints for any text fields, authors use the HTML placeholder attribute. HTML placeholder attribute can be used only if it is native control. However, Authors cannot use same placeholder attribute if it is custom control and it is a problem.

In order to address this problem, ARIA 1.1 introduced new attribute called aria-placeholder and it is equivalent to HTML placeholder attribute. Aria-placeholder defines a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format. It is important to remember that aria-placeholder is not the replacement of the label. Both aria-placeholder and label for the control serve the different purpose. To put it simpler, label is something that helps what type of the information  expected  whereas aria-placeholder is something that enables the user to fill the data with the help of the hint.

When aria-placeholder attribute is defined for the control and control has no value then assistive technologies like screen readers are expected to announce label  and aria-placeholder text together. Similarly, when aria-placeholder attribute is defined for the control and control has value then screen readers are expected to announce both label and it’s value together but not label and aria-placeholder text together.


Author notes

  • Author must use this attribute in the below roles only
  • Author should present this hint to the users only when control has no value. this includes
    • When the control first receives the focus
    • When user erases the previously entered value
  • Authors must ensure that the value of the aria-placeholder is string
  • Authors must implement necessary scripts and functionality for the hint to simulate how HTML placeholder behaves
  • Authors should avoid using aria-placeholder attribute for the native controls(input types and <textarea>)


Sample code snippet

if given


<div contenteditable=”true” role=”textbox” aria-placeholder=”DD/MM/YYYY” id=”sd”>




then the element with role=”textbox” and id=”sd” exposes aria-placeholder=”DD/MM/YYYY”






As you are aware of, making the images accessible is the first and foremost principle of the web accessibility. To make the images accessible, there are number of techniques available. HTML alt attribute can be used to make the simple images accessible by providing the short description. Similarly, HTML longdesc attribute can be used to make the complex images(such as graphs, charts, diagrams, and so on..) accessible by providing the detailed description. Of course, There are number of accessibility challenges with longdesc attribute like sighted users cannot understand existence of long description for the image and so on.. but we are not going to discuss them as part of this post. In any case, there is no such equivalent attribute like longdesc in aria till aria1.0

Aria1.1 introduced aria-details(property) and it is kind of the equivalent to HTML longdesc attribute. Aria-details attribute Identifies the element that provides a detailed, extended description for the object. The value of the aria-details is the ID reference of the element. Unlike aria-describedby attribute, assistive technologies do not present the content of the element referenced by aria-details when the object is in the focus. the reason is that The content of the element referenced by aria-details would not passed into accessibility API as accessible name or accessible description and this is how it is constructed. Let us understand how it works. When aria-details is given for an object and that object receives the focus then assistive technologies like screen readers are expected to announce it as so and so object has detailed description. with this announcement, users of assistive technology would understand that there  is detailed description for this particular object and it is kind of awareness for the user. In addition, assistive technologies must provide the mechanism to navigate from the object to the detailed description section as well as mechanism to navigate back from the detailed description section to the object. when assistive technology users navigate to detailed description section then content must be presented with the semantical structure if the content has any semantics.  In contrast, the content of the element referenced by aria-describedby is going to be presented as a string to the assistive technology users without any semantics.

The content of the element referenced by aria-details or detailed or extended description of the object must be visible to all the users. Some authors may think that both aria-describedby and aria-details  are one and the same as both of them are used to provide the image description. Although the purpose is kind of similar, the way the both attributes present to the accessibility API are not the same as explained above. To make it clear, aria-describedby and aria-details are not one and the same and they both serve the different purposes.

The main advantage of the aria-details property over HTML longdesc attribute is that longdesc attribute can be used only for an image element whereas aria-details attribute can be used for all the elements of the base markup.

Author notes

  • Author must ensure The extended or detailed description that is referenced by aria-details is visible for all the users
  • Authors must provide the value of the aria-details as ID reference
  • Authors must reference single element but not the multiple elements as the value of the aria-details

Notes for assistive technology vendors

  • Assistive technologies must provide the
    • mechanism to navigate from the image object to the extended or detailed description section
    • mechanism to navigate back from the extended or detailed description to the image object
  • when both aria-details and aria-describedby are present for an object and user agents do not support
    • aria-details must take the precedence over aria-describedby

Sample code snippet

if given

<img id=”sd” src=”barchart.jpg” aria-details=”bc”>

<details id=”bc”>

<summary>More information about barchart</summary>

<iframe src=”data:bc/html,<body>barchart</body>


then for the element of id sd expose the aria details relationships on id’s bc and sd