Should ARIA support making elements with structural container roles, like region, interactive?

[mcking65]

Background

This issue is intended to help find a resolution to w3c/aria#681.

ARIA 1.0 and 1.1 support aria-expanded and aria-haspopup on roles that are classified as structures, such as region, group, list, and table. In practice, an element that can be expanded or collapsed, unless it is controlled by another element, is interactive. Similarly, an element that can popup a menu is also interactive.

The ARIA ontology classifies roles into three categories:

1. Widget: An interactive component of a graphical user interface.
2. Structure: A document structural element. Structural roles help assistive technologies distinguish static content from interactive content.
3. Window: A browser or application window.

Generally, structures are not focusable. Some common exceptions are:

1. A landmark region that is the target of a skip link or navigation menuitem.
2. A container with tabindex=-1 used to position focus inside of a modal dialog that contains more content than will fit inside the dialog window.
3. An element with role tabpanel that does not contain any focusable elements at the beginning of its content.
4. An element with role article inside of an element with role feed.
5. An element with role application used to make a custom interactive element.

With the exception of the anomalous role application, these structures are not made focusable in order to provide access to interactive functionality.

Multiple inherritance is rare in the ARIA ontology. One example is a separator, which is a widget if it is focusable and a static structure if not.

So, assistive technologies and testing frameworks can generally rely on the role to determine whether an element needs to be treated as interactive.

The problem

ARIA is currently inconsistent. On one hand, it requires authors to manage focus for all widget roles, and it requires user agents to map widget roles in ways that enable assistive technologies to support interactivity. On the other hand, ARIA does not limit use of states and properties that communicate interactivity to widget roles.

Thus, the ARIA specification permits, even directs, authors to compose UI elements with ARIA that may not be accessible with any assistive technology. Such constructs have been encountered an actual practice. They are not accessible because current assistive technologies and accessibility testing frameworks do not expect structures and windows to be interactive. Structures and windows help assistive technologies manage the adaptation and presentation of content and may not necessarily be represented as an accessible object that is directly perceivable or manipulable by the user. The problems are most apparent in mobile browsers where a keyboard interface is not available.

Possible solutions

1. Limit states and properties that communicate interactivity to elements classified as widgets and adjust the definitions of those states and properties accordingly.
2. Develop implementation patterns for interactive structures and work with developers of platform accessibility APIs to define appropriate mappings for them. Then, add clarifying language, as needed, to the ARIA specification.

[sh0ji]

My preference is to keep structural and widget roles separate (option 1). Structures, almost by definition, are constructs that frame and give context to interactivity. In the physical world, they are the walls, floors, and ceilings that give context to the doors, windows, and furniture that we interact with. If we want to open a wall (aria-expanded?), we don't try to interact with the wall directly--we install a door or window (widget) in it.

Analogies aside, authors are definitely familiar with the idea of containers that serve no interactive function other than to contain an app or set of widgets. Making a structural element interactive is simply a matter of giving that container a structural role rather than trying to give the widget a structural role.

[annabbott]

I agree with Evan: keep structural and widget roles separate (option 1). Kind Regards, Ann annabbott@gmail.com 512-451-8267

…

On Mon, Jan 29, 2018 at 10:24 AM, Evan Yamanishi ***@***.***> wrote: My preference is to keep structural and widget roles separate (option 1). Structures, almost by definition, are constructs that frame and give context to interactivity. In the physical world, they are the walls, floors, and ceilings that give context to the doors, windows, and furniture that we interact with. If we want to open a wall (aria-expanded?), we don't try to interact with the wall directly--we install a door or window (widget) in it. Analogies aside, authors are definitely familiar with the idea of containers that serve no interactive function other than to contain an app or set of widgets. Making a structural element interactive is simply a matter of giving that container a structural role rather than trying to give the widget a structural role. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#578 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARjTmXHKalbEjdaYQsn5XdoBX-n8x9c5ks5tPfDWgaJpZM4RjsLG> .

[mcking65]

This issue was discussed at length in the January 29, 2018 meeting.

Task Force Consensus:
Given that assistive technologies rely on widget roles to convey interaction models, and that both ARIA and current accessibility APIs do not support alternative methods for conveying interaction models (such as control patterns), ARIA states and properties that convey interaction should be limited to widget elements. For example, aria-expanded should only be applied to controlling widgets, not controlled structures.

[accdc]

"Task Force Consensus:
Given that assistive technologies rely on widget roles to convey interaction models, and that both ARIA and current accessibility APIs do not support alternative
methods for conveying interaction models (such as control patterns), ARIA states and properties that convey interaction should be limited to widget elements.
For example, aria-expanded should only be applied to controlling widgets, not controlled structures."

I totally agree.