aria-haspopup(property)

aria-haspopup attribute was present in the aria1.0 as well but few modifications have been made to this attribute in aria1.1. Before we get into that, Let us understand what is popup content as per the specification. Popup content usually appears as a block of content that is on top of other content. It could be menu, dialog, and so on..

In aria 1.0, aria-haspopup values are limited to only true/false. But in aria 1.1, aria-haspopup has list of token values and it is enumerated type. The token values are:

  • Aria-haspopup=”false”, indicates the element does not have any popup
  • Aria-haspopup=”true”, indicates that popup is menu
  • Aria-haspopup=”menu”, indicates that popup is menu
  • Aria-haspopup=”dialog”, indicates that popup is dialog
  • Aria-haspopup=”grid”, indicates that popup is grid
  • Aria-haspopup=”listbox”, indicates that popup is listbox
  • Aria-haspopup=”tree”, indicates that popup is tree

Aria-haspopup=”true” and aria-haspopup=”menu” are one and the same and aria-popup=”true” is for to support the backward compatibility.

Notes for assistive technology vendors

  • Any other value apart from the above mentioned token values should be treated as aria-haspopup=”false”, by assistive technologies which means that element does not have popup.

Author notes

  • Author should use Aria-haspopup attribute only for keyboard focusable elements.
  • Author should not set this attribute for the element that opens tooltip as popup and tooltip are not one and the same.

Sample Code Snippets

button haspopup unspecified

if given

<div id=”test” role=”button”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but not expected to expose aria-haspopup

button haspopup true

Note: as discussed earlier, the ARIA spec says “To provide backward compatibility with ARIA 1.0 content, user agents must treat an aria-haspopup value of true as equivalent to a value of menu.”

if given

<div role=”button” aria-haspopup=”true” id=”test”>

OK

</div>

then for the element of id test, assistive technologies are expected to  expose the button role and aria-haspopup=”menu”

button haspopup false

if given

<div id=”test” role=”button” aria-haspopup=”false”>

OK

</div>

then for the element of id test, assistive technologies  are expected to expose the button role but are not expected to expose aria-haspopup

button haspopup dialog

if given

<div id=”test” role=”button” aria-haspopup=”dialog”>

OK

</div>

 

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of the dialog.

button haspopup grid

if given

<div id=”test” role=”button” aria-haspopup=”grid”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of grid.

button haspopup listbox

if given

<div id=”test” role=”button” aria-haspopup=”listbox”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of listbox.

button haspopup menu

if given

<div id=”test” role=”button” aria-haspopup=”menu”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of menu.

button haspopup tree

if given

<div id=”test” role=”button” aria-haspopup=”tree”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role along with the presence of tree.

 

button haspopup suman

if given

<div id=”test” role=”button” aria-haspopup=”suman”>

OK

</div>

then for the element of id test, assistive technologies are expected to expose the button role but are not expected to expose aria-haspopup as the value “suman” is not the accepted token value.

References

 

aria-colcount(property)

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 3 rows” or something like that. The announcement of 16 columns could be appropriate as DOM contains 16 columns. Let me be very specific with the column count and I would not talk much about row count in this post. However, at times, author might have to hide few columns and show only few other columns. In this case, screen reader announcement may not be appropriate with respect to the total number of columns. I think I confused you a lot. Let us understand this with the simple hypothesis example.

There is table with 16 columns in total. Out of 16 columns, 12 columns are hidden and 4 of them are visually shown. Even DOM contains 4 columns itself. We see this type of show and hide columns when we apply filters in the few applications. In any case, When we run screen reader on this table then obviously screen reader would announce it as “table with 4 columns”. Do you think this announcement is appropriate? 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 16 columns 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 columns”). In a nutshell, the information about the total no of columns is not being announced to the screen reader users along with the visible number of columns and this is problem.

In order to address this problem, aria 1.1 introduced new attribute called aria-colcount. 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-colcount property is defined with 16 to the above table container then screen reader is expected to announce it as “table with 4 of 16 columns” something like that. With this announcement, screen reader user would understand that there are 4 visible columns out of 16 total columns. .

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

 

Author notes

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

 

Example

The following example shows a grid with 16 columns, of which columns 2, 3, 4, and 9 are displayed to the user.

<div role=”grid” aria-colcount=”16″>

<div role=”rowgroup”>

<div role=”row”>

<span role=”columnheader” aria-colindex=”2″>First Name</span>

<span role=”columnheader” aria-colindex=”3″>Last Name</span>

<span role=”columnheader” aria-colindex=”4″>Company</span>

<span role=”columnheader” aria-colindex=”9″>Phone</span>

</div>

</div>

<div role=”rowgroup”>

<div role=”row”>

<span role=”gridcell” aria-colindex=”2″>Fred</span>

<span role=”gridcell” aria-colindex=”3″>Jackson</span>

<span role=”gridcell” aria-colindex=”4″>Acme, Inc.</span>

<span role=”gridcell” aria-colindex=”9″>555-1234</span>

</div>

<div role=”row”>

<span role=”gridcell” aria-colindex=”2″>Sara</span>

<span role=”gridcell” aria-colindex=”3″>James</span>

<span role=”gridcell” aria-colindex=”4″>Acme, Inc.</span>

<span role=”gridcell” aria-colindex=”9″>555-1235</span>

</div>

</div>

</div>

 

References

 

Figure role

All of you would have read the books in school days or college days or even now. You might be wondering that Why I am talking about books. Especially in the books, we see lot of figure patterns. In these books, We will have figure in the right hand side and depiction of that figure in the left hand side. Let us take simple example

In the right hand side, We have the figure called US census statistics on the disability. In the left hand side, we have the information like almost 1 in 5 people reports to have some type of disability(see figure 1. This is how we have it in the textbooks. In general, we call this type of images or pictures as figures. Screen reader announce these type of pictures as “image” or “graphic” , which is not correct interpretation when it compares with the real world. These type of pictures are called as figures in the real world.

figure role helps to bring the same level of experience to the screen reader users as well like the how those type of images are being interpreted in the real world. When figure role is applied then screen reader announces as “figure”, which is more identical, more meaningful, more logical, more appropriate,  when it compares with the real world. Figure role is equivalent of HTML 5 figure. We typically use figure role for the figures in the books. Figure role can be used for the chats, code snippets, diagrams, example text. Parts of a figure  may be user navigable

Author notes

  • Authors SHOULD provide a reference to the figure from the main text, but the figure need not be displayed at the same location as the referencing element.
  • Authors MAY reference text serving as a caption using aria-describedby.
  • Authors MAY provide a label using aria-label or MAY reference text serving as a label using aria-labelledby.

Notes for assistive technology vendors

  • Assistive technologies SHOULD enable users to quickly navigate to figures. Mainstream user agents MAY enable users to quickly navigate to figures.