aria-details(property)

Overview

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>

</details>

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

References

aria-rowcount(property)

Overview

Let us understand how does assistive technologies like screen reader identifies the column count and row count in the table. It is very simple. Screen reader looks at the DOM and calculates how many rows and how many columns are present in the table. Based on that, screen reader would announce the no of columns and no of rows as accordingly. When table receives the focus, For the instance, screen reader would announce like “table with 16 columns and 10 rows” or something like that. The announcement of 10 rows could be appropriate as DOM contains 3 rows. Let me be very specific with the row count in this post. However, at times, author might have to hide few rows and show only few other rows. In this case, screen reader announcement may not be appropriate with respect to the total number of rows. I think I confused you a lot. Let us understand this with the simple hypothesis example.

There is table with 10 rows in total. Out of 10 rows, 6 rows are hidden and 4 of them are visually shown. Even DOM contains 4 rows itself. We see this type of show and hide rows when we apply filters in the few applications and it is kind of how we do in the MS excel. In any case, When we run screen reader on this table then obviously screen reader would announce it as “table with 4 rows”. Do you think this announcement is correct? Answer is yes and no. The reason for yes is that screen reader announces the whatever the DOM contains. The reason for no is that there are 10 rows in total but screen reader user is not aware of this information with the announcement that is being made currently(just to reiterate, the announcement from the screen reader is “table with 4 rows”). In a nutshell, the information about the total no of rows is not being announced to the screen reader users along with the visible number of rows and this is problem.

In order to address this problem, aria 1.1 introduced new attribute called aria-rowcount. When this property is applied with some integer value to the table container then screen reader would announce the visible no of columns as well as total no of columns. Let me take the same above hypothesis example. When aria-rowcount property is defined with 10 to the above table container then screen reader is expected to announce it as “table with 4 of 10 rows” something like that. With this announcement, screen reader user would understand that there are 4 visible rows out of 10 total rows. .

In a broader view, When the number of rows represented by the DOM structure is not the total number of rows available for a table, grid, or treegrid, the aria-rowcount property is used to communicate the total number of rows available, and it is accompanied by the aria-rowindex property to identify the row indices of the rows that are present in the DOM.

 

Author notes

  • Author must use this property for the below roles only
  • Author should not use this property when all the rows are present in the DOM
  • Author must use this property only when portion of rows is present in the DOM at a given moment,
  • Authors MUST set the value of aria-rowcount to an integer equal to the number of rows in the full table.
  • authors MUST set the value of aria-rowcount to -1 if the total no of rows is unknown to indicate that the value should not be calculated by the assistive technologies.

 

Sample code snippet

if given

<div role=’table’ id=’sd’ aria-rowcount=’3′ aria-colcount=’2′>

<div role=’row’>

<span role=’cell’>banana</span>

</div>

</div>

then expose aria-rowcount=”3″ on the element with id=”sd”

 

References

 

aria-colspan(property)

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 the multi-level column headers in this post. Let us understand what is multi-level column headers all about. Usually, we see the pattern like one single column header for all the data cells that are present in that particular column and basically it is called as simple data table. In case of complex table with multi-level column headers, each data cell with respect to the that particular column may have more than one single column header. To put it simpler, a column header would have sub column headers in the complex table with multi-level column headers. To understand which is main column header and which is sub column header visually, authors need to group the related column headers technically(like all the sub column headers need to be grouped with the corresponding main column header by merging the cells with the help of CSS paddings and HTML col 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 columns 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-colspan. Aria-colspan defines the number of columns spanned by a cell or gridcell. When aria-colspan is defined for the cells in the custom table, assistive technologies like screen reader are expected to understand how many columns are spanned and are expected to convey the same information to the users. The information about how many columns 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 column headers, it does not mean that spanning the columns is not limited to column headers. Author can span any columns by using aria-colspan 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-colspan to an integer
    • greater than or equal to 1
    • less than value that prevents overlapping of other cells in the same row. In simple terms, if author wants to span 3 columns then the value of aria-colspan must be set to 3 only but not to 4 or 5 or so.

 

Notes for assistive technology venders

  • Assistive technologies should not expose the value of aria-colspan 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

if given

<div role=”table”>

<div role=”row”>

<div id=”sd” role=”cell” aria-colspan=”2″>country</div>

</div>

</div>

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

 

References

 

Menu, menubar, , and menuitem roles

Since the modern websites are rich in the look wise, it is important to provide the same rich experience to the assistive technology users too. Unfortunately, there are no HTML semantics for the few of the rich controls such as menu, menubar, tab, tree and so on..  usually, authors bring such rich visual look by using CSS design patterns. Let me talk more on menus and menubar in this post. Since there are no HtML semantics for menus and menubar, authors may have to use CSS for the either anchor element or custom container to get the visual appearance of the menu or menubar. When they do so then control might be visually appearing as menu or menubar but assistive technologies do not interpret the same. When assistive technologies do not interpret the way how sighted person perceives the control then it is high chance that assistive technology users would not be aware of the complete functionality of the control. For example, if menu is announced as link by screen reader then it is not the identical experience to the screen reader users. in addition, menu and link might not have the same functionality. In order to provide the semantics for such rich controls, aria introduced menu, menubar, and menuitem roles.

 

Menu role

When we go to restaurant then what is the first thing that we look for. Obviously, we look for the menu. What does it contain? Usually, menu contains the list of the choices that we need to have for the food. On the similar lines, aria menu role is nothing but A type of widget that offers a list of choices to the user. A menu is often a list of common actions or functions that the user can invoke. One thing that we need to remember here is that those list of the options are displayed only when user invokes the menu widget but those list of the options are not visible by default.

The menu role(role=”menu”) is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application. In aria1.1, aria-orientation=”vertical”  has been added as The default implicit value for menu role. The child or required own elements for menu role are menuitem, menuitemcheckbox, menuitemradio.

Menubar role

Menubar role is also kind of the similar concept as menu role. When the list of the choices/options are visually persistent then it is called as menubar. In a simple words, the list of choices are always visible on the screen by default then that complete bar is called as menubar. Most of the people would think that menu is the child of menubar but it is not true. Even though, The menu and menubar are at the same level from the hierarchy wise but they are different in nature. Let me tell you the difference clearly. The list of the choices are displayed when user invokes menu widget for the menu whereas the list of the choices are always visible on the screen by default for the menubar. That is difference between both of them. The child or required own elements roles for the menu and menubar are same and they are menuitem, menuitemcheckbox, menuitemradio.

The menubar role(role=”menubar”) is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands. Authors should ensure that menubar interaction is similar to the typical menu bar interaction in a desktop graphical user interface. In aria1.1, aria-orientation=”horizontal”  has been added as The default implicit value for menubar role and Menubar is usually presented horizontally.

Menuitem role

Menuitem is nothing but An option in a set of choices contained by a menu or menubar. A Menuitem(role=”menuitem”)  may or may not contain sub menu. If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item may be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated. Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets. Authors MAY disable a menu item with the aria-disabled attribute.

Sample code snippet

<ul role=”menubar” id=”appmenu”>

<li role=”menuitem” aria-haspopup=”true”>

Edit

<ul role=”menu”>

<li role=”menuitem”>Undo</li>

<li role=”menuitem”>Redo</li>

<li role=”separator”></li>

<li role=”menuitem”>Cut</li>

<li role=”menuitem”>Copy</li>

<li role=”menuitem”>Paste</li>

</ul>

</li>

</ul>

 

References

 

2.5.3: label in name-New SC in the WCAG 2.1

Success Criterion 2.5.3 Label in Name (Level A): For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

A best practice is to have the text of the label at the start of the name

 

Description

 

There are certain group of people with disabilities, especially who are having learning and physical challenges, use speech recognition software like dragon naturally speaking to access the computers. Let us understand what speech recognition software is all about. Speech recognition software converts speech to text as opposed to the screen readers. Those users of speech recognition software access the computers with the speech input and there are voice commands to perform the regular activities on the computer like opening MS word document, , opening files/folder, sending the email, browsing the web and so on.. now that we understand that how those users of speech recognition software access the computers. On the similar lines, when user is trying to activate the send button by using voice commands after composing the email, for the instance, send button does not get activated in spite of the multiple attempts. The reason could be that, even though there is a visible text as send for the user interface control but the control may not have same text as an accessible name in the accessibility tree rather control has the submit as an accessible name in the accessible tree. As visible name of the control is send and accessible name of the control is submit, speech recognition software never understand and never activate this control  when user is trying to activate send button with the speech input. This creates problem and intern it impacts the ability to use the control itself for those users of speech recognition software.

In order to address this problem, WCAG 2.1 introduce this new SC. The intent of this Success Criterion (SC) is to help ensure that people with disabilities who rely on visual labels can also use those labels programmatically. In other words, the accessible name of the control must contain the text that is visible on the control but It does not mean that accessible name of the control need not to be identical with the visible label of the control. In addition, when the accessible name is different from visible label of the control then it is high chance that speech input users may accidently activate the hidden commands. As a result, speech input users get confused and disoriented with the unexpected actions. Text to speech(screen reader) users get best experience when accessible name of the control is matched with the visible name of the control.

Pass scenarios

  • Accessible name of the control matches visible label of the control
  • the words of the visible label in the accessible name are not scattered and are in the same order as they are in the visible label

 

References

 

1.4.12: Text Spacing-New SC in the WCAG 2.1

Success Criterion 1.4.12 Text Spacing (Level AA): In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

 

Description

There are certain group                 of low vision users, especially people who are suffering from Age-related Macular Degeneration, read the content on the web by customizing the original view. What does it mean? Let us understand this. Few low vision users feel very difficult to read the content on the web in it’s default view.  The reason is that block of text seems to be cluttered due to the small spacing for the low vision users and this makes it hard to read. To overcome this challenge, those low vision users use the stylesheets/extensions/bookmarklets  to make the same block of the text readable. You might be wondering what exactly these tools do. These tools enable the low vision user to adjust the spacing between characters/words/lines/paragraphs on the web and that intern helps the user’s readability. So far all is good and we understand that there are tools/assistive technologies that enables the low vision user to adjust the text spacing. However, when they try to adjust the text spacing via these tools then what if the text is cut off vertically, text is cut of horizontally, text is overlapped, and text is fixed. When we encounter such problems while using those tools then it is going to be problem for the low vision users to read the content on the web.

In order to address this problem, WCAG2.1 introduced this new success criterion. The intent of this Success Criterion (SC) is to ensure that people can override text spacing to improve their reading experience. Having said that, do you think user can adjust/override the text spacing to any extent. Answer is no. the success criterion clearly specifies that distances between paragraphs, lines, words and characters must be able to be increased to certain values without leading to loss of functionality or readability. The below are the specifications for the same.

  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

 

author responsibility

This SC does not dictate that authors must set all their content to the specified metrics. Rather, it specifies that an author’s content has the ability to be set to those metrics without loss of content or functionality. The author requirement is two-fold:

  • to not interfere with a user’s ability to override the author settings, and
  • to ensure that content modified to Success Criterion 1.4.12’s metrics does not break content.

 

Benefits

  • People with low vision who require increased space between lines, words, and letters are able to read text.
  • People with dyslexia may increase space between lines, words, and letters to increase reading speed.
  • Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes. To put it more simpler, Many people with cognitive disabilities have trouble tracking lines of text when a block of text is single spaced. Providing spacing between 1.5 to 2 allows them to start a new line more easily once they have finished the previous one.

 

Pass scenarios

The below are the few scenarios where this success criterion is met

  • Spacing can be adjusted to the SC’s metrics
  • Text is not cut off in the both directions(horizontally and vertically)
  • Text is not overlapped
  • Plugin technologies that have a built-in ability to modify styles to the specified metrics.

Not applicable/exceptional  scenarios

This SC does not applicable for the below scenarios

  • PDF files as it is not implemented using markup
  • Video captions in the video player
  • Images of text that is built with canvas technology
  • There are cases where a text style property is not used in a language or script(e.g. applying word spacing for Japanese language would not have any effect as the language does not have words itself.

How to test this SC

Follow the below step by step instructions to test this SC

  1. Click Text Adaptation Bookmarklet – Steve Faulkner
  2. add the bookmarklet to the browser by following simple instructions that are given in the same link
  3. once the bookmarklet is added, open any web page
  4. navigate to browser bookmarks and activate “text spacing” bookmarklet
  5. the same web page displays with the SC metrics text spacing and check if the text is readable
  6. that is all you are done!

Techniques

Here are the few techniques that author can use to meet this success criterion

 

References

 

 

aria-colindex(property)

Overview

 

As discussed in aria-colcount(property) post, at time, author might not want to show all the total columns 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 columns in the DOM. When author wants to show only the portion of the columns of the table in the DOM then it is  suggested to use aria-colcount property to communicate the total no of columns to the assistive technology users. Up to this, we are clear with the concept. However, using aria-colcount alone would not be sufficient to convey all the table properties to the assistive technology users. Since only the portion of the columns are visible in the DOM, assistive technologies like screen readers do not understand which cell/column has the data. As a result, screen readers might end up with incorrect column 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-colindex. When aria-colindex property is set on the cell container of the table then screen readers would understand column index of that cell and announces the column index accordingly. Let me elaborate this little bit more. As have been discussing, this property should be used only the portion of the columns of the tables are available in the DOM. By considering this important point in the mind, let us think there are 4 columns(column2, column3, colunm5, and column9) of the table are available in the DOM out of 16 total columns. If aria-colindex is set as 2 for the column2 cell then screen readers would announce the column2 and this announcement is appropriate. Failing to set this attribute may result the incorrect column index announcements by screen reader software and this intern confuses the users a lot. When aria-colcount is set for the complete table container then it is necessary to set the aria-colindex to define the position of the visible column of that table.

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

 

Author notes

  • Authors should use this property for the below roles only<
    • Cell
    • Row
    • Column header
    • Gridcell
    • Rowheader
  • Authors should not set/define this attribute If all of the columns are present in the DOM as user agent can automatically calculate the column index of each cell or gridcell
  • Authors should set/define this attribute only when portion of the columns is present in the DOM at a given moment,
  • this attribute is needed to provide an explicit indication of the column of each cell or gridcell with respect to the full table
  • Authors MUST set the value for aria-colindex to an integer greater than or equal to 1,
  • Aria-colindex must be greater than the aria-colindex value of any previous elements within the same row,
  • Aria-colindex must be less than or equal to the number of columns in the full table
  • aria-colindex cannot be greater than aria-colcount, unless aria-colcount is unknown (e.g. value -1)
  • aria-colindex must be set on the start of the span if the cell or gridcell spans multiple columns or multiple rows
  • If the set of columns which is present in the DOM is contiguous, and if there are no cells which span more than one row or column in that set,<
    • aria-colindex is not needed to set on the every cell
    • aria-colindex can be set on the row element with a value equal to the the index number of the first column in the set. Browsers will then compute a column number for each cell in the row.
  • aria-colindex needs to be set on each cell in the row If the set of columns which is present in the DOM is noncontiguous

 

Sample code snippet

if given

<div role=”table”>

<div role=”row”>

<div id=”SD” role=”cell” aria-colindex=”4″ aria-colcount=”8″>suman damera</div>

</div>

</div>

then expose aria-colindex=”4″ on the element with id=”SD”

 

References

 

 

 

4.1.3: Status Messages-New SC in the WCAG 2.1

Success Criterion 4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Description

As you may aware of, people with visually challenged use the screen reader software to browse the website or access the information on the web. While browsing the website, it is natural thing for anyone to perform some actions like submitting the form, adding items to the cart,  and so on..) in order to get the information that he/she is looking for.  when an action is performed then updates or changes(popping the error messages, success messages after adding the item to the cart, and so on..)  may take place then and there without page refresh on the few websites. Those updates are obvious for the visual users but the same updates may not be obvious to the screen reader users. When screen reader users are not aware of these updates/changes then they do not get the same experience like how the sighted person experiences while browsing the information. As a result, screen reader users may not understand what is going on the page and might end up with the confusion/frustration

In order to address these type of situations, WCAG2.1 introduced this new checkpoint. The intent of this Success Criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn’t unnecessarily interrupt their work. Having said that, do you think all the changes that takes place in the dynamic website deal this success criterion? Answer is no. The scope of this Success Criterion is specific to changes in content that involve status messages. You might be wondering what status message is about. Status message has specific definition in the WCAG. There are two main criteria that determine whether something meets the definition of a status message:

  1. the message “provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;”
  2. the message is not delivered via a change in context.

 

The changes to the content need not to be always addition of new text to the screen and may be in the other formats too(like non-displayed text specific to assistive technology users and non-text content. As long as the changes to the content meet above conditions, it fits within this success criterion.

Benefits

  • new content is announced to the screen reader users When appropriate roles or properties are assigned to status messages, in such a way as to assist blind and low vision users.
  • Assigning proper roles or properties to status messages provides possible future uses and personalization opportunities to assistive technologies for users with cognitive disabilities. assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user

Pass scenarios

The below are the few scenarios where this success criterion is met

  • after recipient email address is selected from the suggested list in the email application, recipient email address is added on the screen. The screen reader announces as suman damera added. It is important to understand that the text “added” may not be visible on the screen but screen reader announces as suman damera added. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • after recipient email address is removed from the list of selected recipients in the email application, recipient email address is removed from the screen. The screen reader announces as suman damera removed. It is important to understand that the text ‘removed” may not be visible on the screen but screen reader announces as suman damera removed. In order to give the context to the screen reader users, the extra piece of information is necessary in the form of non-displayed content
  • while entering the password at the password text area in the few signup forms, there is a visual indication how strong the password is. . screen reader announces weak/weaker/strong
  • after the incorrect form submission, there is a message on the screen like 5 errors are found. screen reader announces as “5 errors are found”
  • after the successful form submission, there is message on the screen like your form has been successfully submitted, will contact you soon. screen reader announces the same.
  • after adding the items to shopping cart by using add to cart button of the product in the eCommerce websites, cart count gets updated visually like 0 to 1, 1 to 2, and so on.. screen reader announces as “item has been added to the cart and currently cart has 2 items”

 

Not applicable/exceptional  scenarios

The following scenarios identify situations where no additional author action is necessary. All cases are excepted from this Success Criterion since they do not meet the definition of “status messages.”

  • When an error message is displayed in the dialog then authors need to place the focus on the dialog. By doing so, screen reader announces the error message. In addition, this is not a change of content and it is change of context. Thus, this scenario does not fit into current success criterion.
  • When there is an expand/collapse element(such as menu, select, accordion, tree, ) and screen reader announces the state of the element(expand/collapse) appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion
  • When there is tablist widget and screen reader announces the selected state of the tab item appropriately then user understands whether content is revealed or hidden with the help of state itself. Thus, this scenario does not fit into current success criterion

 

 

Techniques

Here are the few techniques that author can use to meet this success criterion

References

 

aria-modal(property)

First of all, Let us understand What is a modal. Modal is something that interrupts your current work flow on your main page and usually, user navigation is limited within the modal element itself. In other words, users cannot access the background content when modal is displayed. Even though visually the background content is inert/grade out, it is high chance that screen reader users can access the background content, which is a problem.

To address this problem, what we have been doing is that we use aria-hidden=”true” attribute to hide the background content from the screen reader users. When modal is closed, we flip the aria-hidden value from true to false, so that screen reader users can access the content when they are returned to the actual web page. These are the techniques that we have been following to hide/unhide the background content from the screen reader users.

Aria 1.1 introduced the aria-modal attribute to hide the background content directly instead of using aria-hidden attribute. Authors should use aria-modal attribute in conjunction with dialog/alertdialog role. When aria-modal is set to true in the dialog/alertdialog container then the expectation is that:

  1. Assistive technologies do not expose the background content
  2. User navigation is limited to the modal elements itself
  3. Assistive technology should place the focus on the modal element when it is displayed unless the focus has explicitly been placed else where

all these things are being taken care automatically when aria-modal=”true” is used. Imagine’, how cool it is. Hence,  we don’t need to use aria-hidden attribute any more.

Author notes

  • Author should use aria-modal attribute in conjunction with dialog/alertdialog role.
  • When a modal element is displayed, authors MUST ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog.

Sample code snippet

if given

<body>

<h1 id=”Test2″>Modal Dialog Box Test</h1>

<div role=”dialog” aria-modal=”true” id=”test”>

<input type=”button” value=”ok”/>

</div>

</body>

then the element with role=”dialog” and id=”test” exposes aria-modal=”true”

 

 

References

 

 

Cell Role

When It is not possible to construct the tabular content by using HTML <table> tag for any reason then they are called as custom tables. On the similar lines, when we cannot use the HTML <table> tag then it is obvious that descendants of the HTML table cannot be used. When I say descendants then what does it mean with respect to the HTML <table> tag. The descendants of HTML <table> tag could be <td>, <th> <tr>, <tbody>, <tfooter>, <thead> and so on.. in other words, authors cannot use all the mentioned descendants unless HTML <table> tag is being used to construct the tabular content. Each descendant conveys some or other semantical information to the assistive technology users. Let me talk more about <t> descendant. <td> tag conveys the semantical information to the assistive technology users that it is a cell. Unfortunately, custom tables are constructed with <div> and <span> tags. Divs and spans do not convey the any semantical information to the assistive technology users and this is a problem.

In order to address this problem, aria 1.1 introduced table and cell roles. To provide the semantics to the custom table, author must provide Table role to the entire container. Similarly, to provide the cell semantics in the custom table, author must provide cell role. Cell role is related to gridcell and It is equivalent of HTML <td>. All the context that I made about the tables is related to the static tables but not related to interactive tables. To be very clear and precise, cell role must be used only for static tables that are having table role.

 

Author notes

 

  • Authors MUST ensure elements with role cell are contained in, or owned by, an element with the role row.

 

Code snippet

<div id=”foo” role=”table” aria-colcount=”8″>

<div role=”row”>

<span id=”test” role=”cell” aria-colindex=”4″ >test cell</span>

</div>

</div>

References