title: aria role="application" and tab-trapping
body: <p><a href="https://hiddedevries.nl/en/blog/2017-01-29-using-javascript-to-trap-focus-in-an-element" rel="nofollow noreferrer">Tab trapping</a> is a fairly well established pattern (<a href="https://css-tricks.com/a-css-approach-to-trap-focus-inside-of-an-element/#article-header-id-4" rel="nofollow noreferrer">example</a>). Typically for the sake of accessibility, it allows keyboard users to navigate inside dropdown menus and modals. What's concerning however are the implications for users now that the native functionality of the tab event has been overwritten with a new behavior (looping). This isn't a big deal for sighted users, but it is problematic for users of Assistive Technologies like NVDA and JAWS that critically rely on that native tab functionality.</p>
  
  <p>WAI-ARIA has a solution for informing Assistive Technologies of when native keyboard functionality has been overwritten in the form of <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Application_Role" rel="nofollow noreferrer">aria-role="application"</a>:</p>
  
  <blockquote>
    <p>Keyboard interaction is completely under the web author's control and
    can be anything associated with the particular widget being
    implemented. In a slides application, for example, a widget could be
    created that uses the arrow keys to position elements on the slide,
    and uses audio feedback via an ARIA live region to communicate the
    position and overlap status with other objects. Focus is being managed
    via aria-activedescendant.</p>
    
    <p>The tab , Space and Enter keys, as well as Escape , must be handled by
    the application. The one exception is if focus is set to a standard
    widget inside the application that supports keyboard navigation from
    the browser, for example an input element.</p>
  </blockquote>
  
  <p>This would imply that <strong>any component that employs tab-trapping should necessary have a <code>role="application"</code>, <em>always</em>.</strong></p>
  
  <p>However I don't believe this common practice. Sites like <a href="https://www.target.com/" rel="nofollow noreferrer">Target.com</a> for example (that use tab trapping on their dropdown menu) categorize it as a list, as seen here in the website Accessibility Tree:
  <a href="https://i.stack.imgur.com/hCaUd.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/hCaUd.png" alt="enter image description here"></a></p>
  
  <p>I'd appreciate any experienced perspectives on this. Am I interpreting ARIA correctly here? Should components that employ tab-trapping <em>always</em> be decorated with <code>role="application"</code>?</p>