• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Digital A11Y

Digital A11Y

Your Accessibility Partner

  • About
  • Articles
  • WAI-ARIA
  • WCAG
  • Resources
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact

WAI-ARIA: Role=Application

A structure containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.

Description

A structure containing one or more focusable elements requiring user input, such as keyboard or gesture events, that do not follow a standard interaction pattern supported by a widget role.

Some user agents and assistive technologies have a browse mode where standard input events, such as up and down arrow key events, are intercepted and used to control a reading cursor. This browse mode behavior prevents elements that do not have a widget role from receiving and using such keyboard and gesture events to provide interactive functionality.

When there is a need to create an element with an interaction model that is not supported by any of the WAI-ARIA widget roles, authors MAY give that element role application. And, when a user navigates into an element with role application, assistive technologies that intercept standard input events SHOULD switch to a mode that passes most or all standard input events through to the web application.

For example, a presentation slide editor uses arrow keys to change the positions of textbox and image elements on the slide. There are not any WAI-ARIA widget roles that correspond to such an interaction model so an author could give the slide container role application, an aria-roledescription of “Slide Editor”, and use aria-describedby to provide instructions.

Because only the focusable elements contained in an application element are accessible to users of some assistive technologies, authors MUST use one of the following techniques to ensure all non-decorative static text or image content inside an application is accessible:

  1. Associate the content with a focusable element using aria-labelledby or aria-describedby.
  2. Place the content in a focusable element that has role document or article.
  3. Manage focus of descendants as described in Managing Focus, updating the value of aria-activedescendant to reference the element containing the focused content.

Example

HTML Example

<div role="application">
<h1>Calculator</h1>
<input id="num1" type="text"> + <input id="num2" type="text"> =
<span id="result"></span>
</div>

Date Picker Example

<div id="application" role="application">
<label id="date_label" for="date">Date</label>:
<input id="date" type="text"/>
<button id="bn_date">Select Date...</button>
<div id="dp1" class="datepicker" aria-hidden="true">
<div id="month-wrap">

<div id="bn_prev" role="button" aria-labelledby="bn_prev-label"
tabindex="0"><img class="bn_img"
src="http://www.oaa-accessibility.org/media/examples/images/prev.png"
alt="<<"/></div>

<div id="month" role="heading" aria-live="assertive" aria-atomic="true">February 2011</div>

<div id="bn_next" role="button" aria-labelledby="bn_next-label"
tabindex="0"><img class="bn_img"
src="http://www.oaa-accessibility.org/media/examples/images/next.png"
alt=">>"/></div>

</div>
<table id="cal" role="grid" aria-activedescendant="errMsg" aria-labelledby="month" tabindex="0">
<thead>
<tr id="weekdays">
<th id="Sunday"><abbr title="Sunday">Su</abbr></th>
<th id="Monday"><abbr title="Monday">Mo</abbr></th>
<th id="Tuesday"><abbr title="Tuesday">Tu</abbr></th>
<th id="Wednesday"><abbr title="Wednesday">We</abbr></th>
<th id="Thursday"><abbr title="Thursday">Th</abbr></th>
<th id="Friday"><abbr title="Friday">Fr</abbr></th>
<th id="Saturday"><abbr title="Saturday">Sa</abbr></th>
</tr>
</thead>
<tbody>
<tr><td id="errMsg" colspan="7">Javascript must be enabled</td></tr>
</tbody>
</table>
<div id="bn_prev-label" class="offscreen">Go to previous month</div>
<div id="bn_next-label" class="offscreen">Go to next month</div>
</div>
</div>

Characteristics

Superclass Role

  • structure

Supported States and Properties

  • aria-activedescendant

Inherited States and Properties

  • aria-atomic
  • aria-busy (state)
  • aria-controls
  • aria-current (state)
  • aria-describedby
  • aria-details
  • aria-disabled (state)
  • aria-dropeffect
  • aria-errormessage
  • aria-flowto
  • aria-grabbed (state)
  • aria-haspopup
  • aria-hidden (state)
  • aria-invalid (state)
  • aria-keyshortcuts
  • aria-label
  • aria-labelledby
  • aria-live
  • aria-owns
  • aria-relevant
  • aria-roledescription

Name From

  • author

Accessible Name Required

  • True

Semantic HTML

No HTML element equivalent.

Reference

W3C (opens new window)

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

Primary Sidebar

Get Digital A11Y in Your Inbox

Recent A11Y Articles

  • Understanding SC 4.1.3 Status messages
  • Understanding SC 2.5.4 Motion Actuation
  • Understanding SC 2.5.3 Label in Name
  • Knowbility looking for mentors in its Accessible Internet Rally
  • Understanding SC 2.5.2 Pointer Cancellation

Recent Comments

  • Al on Understanding SC 4.1.2 Name, Role, Value
  • Randy on Screen Readers & Browsers! Which is the Best Combination for Accessibility Testing?
  • Raghavendra Satish Peri on Screen Readers & Browsers! Which is the Best Combination for Accessibility Testing?
  • Raghavendra Satish Peri on Understanding SC 1.4.12 Text Spacing
  • Raghavendra Satish Peri on Understanding SC 4.1.2 Name, Role, Value

A11Y Categories

  • Design
  • Events
  • HTML
  • IOS
  • Mobile Accessibility
  • News
  • Tools
  • Uncategorized
  • WAI-ARIA
  • WCAG
  • Web Accessibility

  • Privacy Policy
  • Sitemap
© 2021 Digital A11Y