Clarification on `role="application"` - can it be interacted with directly or only have interactive children?

[oscarhermoso]

Describe your concern

Clarification on role="application" - can it be interacted with directly or only have interactive children?

If so, would a single, focusable element with role="application" satisfy the ARIA requirements for the role?

<canvas onclick="handle" onkeypress="0" role="application" tabindex="0" />

Relates to:

• fix: define role="application" as an interactive ARIA role sveltejs/svelte#8975
• Build warning - A11y: <div> with mousedown handler must have an ARIA role ValentinH/svelte-easy-crop#48
• aria-role="application" should be allowed when a widget role is required. dequelabs/axe-core#890

Link to the version of the specification or documentation you were looking at at.

Link to documentation: https://www.w3.org/TR/wai-aria-1.2/#application

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? Editors draft has same content as ARIA 1.2

[scottaohara]

it seems to me, upon reviewing the easy crop widget, that the underlying issue is the fact there are no focusable descendants of this UI, such as range sliders to adjust the position or zoom of the image being cropped.

the current examples available in the github repo aren't presently keyboard accessible (maybe that's what you're trying to fix?) but it does seem like the LOE to implement and describe all the keyboard behaviors for a single application wrapping element would be rather high - but if there were nested interactive keyboard elements that provided their own distinct functions for the cropping (again range sliders could be used to zoom in/out, or adjust the position of the image being cropped. heck, the button to perform the crop could very well be a child of the application role as well).

Another thing to consider here is that with the upcoming WCAG 2.2 drag movements - this component is going to need a to allow for someone using a pointer device (mouse/touch, etc) to be able to achieve the outcomes of what is presently reliant on dragging movements without having to perform such dragging movements. Again, nested interactive elements that a pointer device could use instead (thus also achieving the 2.1.1 rule) would probably be the most straight forward way to achieve this goal.

All that said, the wg can discuss your high level ask - though presently the spec is pretty clear that the expectation is there would be interactive elements within the application role container... maybe that should/could change? But even if it does, that might be for nothing if you have to add nested interactive elements to address all the things i mentioned above, anyway.

[oscarhermoso]

@scottaohara Thankyou!

I completely agree the Cropper component isn't very accessible, and I'm intending raise a PR to improve it soon. Developers that import the component are able to implement external controls, as partially seen the react-easy-crop example, but the core functionality of dragging/positioning is not accessible.

Given a scenario where a developer implements the Cropper component in a more accessible way, using role="application" as you described...

<script>
  import Cropper from 'svelte-easy-crop';
  let zoom = 2.0;
</script>

<div role="application" aria-roledescription="Image cropper" aria-describedby="cropper-description">
  <p id="cropper-description">...</p>
  <Cropper image="image.png" {zoom} />
  <input type="range" bind:value={zoom} min="1.0" max="5.0"  />
  <button type="button" on:click={submitCrop}>
<div>

...with an improved Cropper component, where the element with class="container" can be focused and receives arrow-keys events to move the image within (maybe something like this) .

<!-- @component Cropper.svelte -->
<script>...</script>
<div class="container" role="???" tabindex="0" on:mousedown={onMouseDown} on:keypress={onKeyPress}>
  <img src={image} style="scale({zoom}); ..."></img>
  <div class="cropperArea" ... />
<div>

What would be an appropriate ARIA role for the element with class="container" to satisfty success criteria for WCAG 4.1.2 Name, Role, Value?

Previously, I believed was that this was the ideal use case for role="application", as the user interactions wouldn't be well described by any other widget roles, and that marches the opening description of the ARIA role for 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.

Generally, the existing widget roles aren't great at describing draggable elements, or elements that move in 2D space.

Also... I appreciate the heads up on WCAG 2.2 Drag Movements, but will need to give it some thought. I agree that the Cropper component would not be accessible for those without the ability to drag, but I've also worked with people with reduced motor function on touch screen devices. Anecdotally, they would find it significantly easier to drag an image into position than use nested interactive elements to position that image.

---

TL:DR; If the element with role="application" is not interactive, and only contains interactive children - what ARIA role should I be adding to interactive elements that don't fit the description of existing widget roles?

[jnurthen]

Personally I would support clarifying language that this is allowed. If we allow

<div  role="application">
<canvas onclick="handle" onkeypress="0" tabindex="0" />
</div>

then I see no reason that we wouldn't allow

<canvas onclick="handle" onkeypress="0" role="application" tabindex="0" />