Month: June 2018

Did you see any website without search form field? Almost every website usually has this search form field. The purpose of having this search form field on the website is to search as per user need and navigate to the respective sections quickly  instead of browsing the entire website. Imagine, this search form field is not constructed with html input type search and is constructed with the custom controls then this search form control might not be accessible to assistive technology users. if this search form control cannot be constructed with html input type search for some reason then we are left with the option of using new aria1.1 searchbox role to make this custom control accessible.

Aria1.1 Searchbox role can be used for the type of textbox intended for specifying search criteria . When searchbox role is applied to container then screen readers are expected to announce as “search edit type and text” or something like that. Search role and searchbox role are different from each other and they are not identical/same. To be precise, The role=”searchbox” must be provided for focusable element whereas role=”search” is the landmark that includes focusable active elements. On the similar lines, textbox role and searchbox role are different from each other and they are not same/identical. Searchbox role is equivalent of the html <input type=”search” element.

Author notes

• Author must set the accessible name when searchbox role is used

 

 

Code snippet

 

<div id=’test’ role=’searchbox’ contenteditable=’true’></div>

 

References

• aria1.1 specification-searchbox role

 

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

• aria1.1 specification-aria-haspopup

 

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
  • Table
  • Grid
  • Treegrid
• 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

• aria1.1 specification-aria-colcount
• wai aria1.1 aria authoring practices-aria-colcount