Tag: code snippets

Overview

 

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>

</div>

</div>

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

References

• aria1.1 specification: aria-rowspan
• wai aria authoring practices: aria-rowspan

 

Overview

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

 

<body>

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

</body>

 

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

 

References

• aria1.1 specification: aria-keyshortcuts

Overview

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
  • Textbox
  • Searchbox
• 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”>

“DD/MM/YYYY”

</div>

 

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

 

References

• aria1.1 specification: aria-placeholder(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

• aria1.1 specification: aria-details(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
  • Table
  • Grid
  • Treegrid
• 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

• aria1.1 specification:aria-rowcount
• wai aria1.1 aria authoring practices:aria-rowcount

 

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

• aria1.1 specification: aria-colspan
• wai aria authoring practices: aria-colspan

 

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

• Aria1.1 specification-menu role
• Aria1.1 specification-menubar role
• Aria1.1 specification-menuitem role
• WAI aria1.1 authoring practices-navigation menubar example

 

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

• aria1.1 specification-aria-modal(property)
• aria1.1 authoring practices: aria-modal working example

 

 

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

• aria1.1 specification-cell role
• aria1.1-table and cell working example

 

 

 

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