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”
- 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”
- 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”
- 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.
- 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
Sample Content </li>
Then assistive technologies like screen reader would not
announce the list semantics
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
- none (synonym for presentation)
13 new states & properties (now 48 total)
The following new states and properties have been added
8 roles with major updates
The below roles have been updated in terms of it’s usage
- Application: it is not a landmark and needs to be thought as last option
- Article: along with the original behavior, in addition, it is the child of feed role
- Combobox: it should also own an element that has a role of tree, grid, or dialog along with the role of listbox.
- Dialog: it should be considered as a window and assistive technologies should not pass through keys.
- Document: it is Recommended to use inside application elements.
- Grid: spec provides the additional guidance on how focus management should be, and how aria-readonly should be used
- Region: it should be considered as a landmark
- 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
- aria-activedescendant: editorial change
- aria-autocomplete: editorial change
- aria-busy: it should not be limited to live regions
- aria-haspopup: it should support additional values such as menu, grid, dialog, tree, listbox along with the original values(true/false)
- aria-hidden: editorial change
- aria-level: it should be required for the heading role
- aria-orientation: default value should be undefined and it is allowed for more roles
- aria-readonly: it should support other roles too such as combobox, listbox, radiogroup, slider, and spinbutton.
- aria-posinset: it should Support other roles too such as radio, tab, article in feed.
- aria-setsize: it should Support other roles too such as , radio, tab, article in feed.
- aria-setsize: the value should be set to “-1” if the size is unknown.
The following attributes have been deprecated in aria1.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.
- Aria-rowindex property must be used for the below roles only
- Column header
- 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
<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 must use this attribute on the below roles only
- 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 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 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
<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”