Each ARIA role entry characteristics table should have a "can have focusable descendants" entry

[Wildebrew]

The problem

One of the most critical misuses of ARIA that I have come across is people putting an interactive widget role (such as role="button" role="checkbox" or role="tab") on an element that contains a section of content (that contains text, semantics and other interactive elements).

This is particularly common when people misunderstand the tab construct and put role="tab" on the tabpanel element. I've seen this happen, even on an accessibility vendor website (I won't divulge .which)

The widget role flattens the contents of the element to a string and removes all semantics, including the semantics and accessible names of interactive elements.

Ascreen reader will announce the following as "Apply for a credit card your name sign up, tab"

<div role="tab">
<h4>Apply for a credit card</h4>
<label for="name">Your name</label>
<input type="text" id="name">
<button.Sign up</button.
</div>

This has the effect of making the tabpanel content unreachable by a screen reader user.

Yet the ARIA spec does not clearly forbid this, and tools that validate ARIA fail to flag it as an accessibility issue (even if, in practice this is the most destructive misuse of ARIA).

A solution

To help resolve this I am picturing an entry in the characteristics table for each role entry along the lines of "allows interactive descendants" with a "yes" or "no" value.

• For a tab, a button, a link, a checkbox etc. this value would be no.
• For a document or live region role this would be a yes.

I admit I haven't thought through every single role entry yet, but I think the vast majority are pretty straight-forward. If this entry is approved and documented in the ARIA spec, accessibility testing tools that validate ARIA can perform the necessary checks and flag misuses of widget roles that will hide interactive elements.

[jnurthen]

How is this different to Presentational Children? https://w3c.github.io/aria/#childrenArePresentational

You can find the full list of roles this applies to at https://w3c.github.io/aria/#tree_exclusion

[Wildebrew]

There is a significant difference in my mind.

One (presentational children) says, "hey, you may not realize that your button will have a long and unwieldy name and if you put headings inside it they are not going to be communicated". the other says "hey, if you put an interactive element inside this widget, a screen reader user can't get to it, not at all, also it is illegal nesting, just like it is in HTML.".

The first is a minor to a major inconvenience (but still just inconvenience), it is not a normative guidance on what is allowed and what isn't. , the second is a critical defect that prevents users from performing one or more actions on the website.

This is about establishing guidelines that allow automated tools to prevent these types of mistakes from ruining a webpage.

A presentational child is not an an ARIA violation, but explicitly stating that an element with the given role cannot have interactive children establishes clear guidance that tools can interpret to spot critical violations.

On 8/7/19, James Nurthen notifications@github.com wrote:

How is this different to Presentational Children? https://w3c.github.io/aria/#childrenArePresentational

You can find the full list of roles this applies to at https://w3c.github.io/aria/#tree_exclusion

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/aria/issues/1028#issuecomment-519284339

-- Work hard. Have fun. Make history.

[accdc]

Hi, I've taken a look, and I think this could be better called out within the spec for related widget roles to make this clearer, but the spec does mention in a couple locations where specific criteria need to be observed.

5.2.8 Presentational Children http://www.w3.org/TR/wai-aria-1.1/#childrenArePresentational

5.3.2 Widget Roles http://www.w3.org/TR/wai-aria-1.1/#widget_roles

composite (abstract role) http://www.w3.org/TR/wai-aria-1.1/#composite

Basically, any widget role that is not explicitly identified as a composite widget, is not allowed to have interactive focusable descendants.

It seems to me that the compliance checkers need to be updated to reflect this better.

[Wildebrew]

I think in order to do that, this requirement needs to be stated more explicitly in the spec. Tool developers are reluctant to draw conclusions about what is permitted and what isn't, it should be clearly and explicitly stated in the spec.

Developers that are new to accessibility do not spend time reading the ARIA spec and connecting concepts from different sections. They need requirements like this to be explicitly stated in one place, and the characteristics table is where I tell my developers to look when in doubt (and when I'm not available).

My point is that, for something as critical as this, people shouldn't not have to read and deduct.

On 8/8/19, Bryan Garaventa notifications@github.com wrote:

Hi, I've taken a look, and I think this could be better called out within the spec for related widget roles to make this clearer, but the spec does mention in a couple locations where specific criteria need to be observed.

5.2.8 Presentational Children http://www.w3.org/TR/wai-aria-1.1/#childrenArePresentational

5.3.2 Widget Roles http://www.w3.org/TR/wai-aria-1.1/#widget_roles

composite (abstract role) http://www.w3.org/TR/wai-aria-1.1/#composite

Basically, any widget role that is not explicitly identified as a composite widget, is not allowed to have interactive focusable descendants.

It seems to me that the compliance checkers need to be updated to reflect this better.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/aria/issues/1028#issuecomment-519731189

-- Work hard. Have fun. Make history.

[JAWS-test]

In this context, it should not only be clarified whether an element may have child elements that can be operated, but also whether it should have child elements with roles at all, except those that are required (see https://github.com/w3c/aria/issues/1034).

Or whether text that is not within the required child elements should be output at all. For HTML, for example, it is clear that text within select and table that is not in option or tr or th is not output. What about text inside role=listbox that is not inside role=option, or text inside role=table that is not inside role=cell?

Currently, for example, both JAWS and NVDA with IE 11 output the entire contents of a listbox, including the contents outside of role=option. In Chrome and Firefox only selected list entries are output by the screenreader:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Required Owned Elements</title>
    </head>
    <body>
        <div role=listbox aria-multiselectable=true>
            <h2>h2</h2>
            <div role=option>option 1</div>
            <div role=option aria-selected=true>option 2</div>
            <div role=option>option 3</div>
            text
            <div role=treeitem aria-selected=true tabindex=0>treeitem</div>
        </div>
    </body> 
</html>

However, the text inside grid and outside gridcell is always output by JAWS (Chrome, Firefox, IE 11).

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Required Owned Elements</title>
    </head>
    <body>
        <div role=grid>
            <h2>h2</h2>
            <div role=row>
                <div role=gridcell>gridcell 1</div>
                text
                <div role=gridcell>gridcell 2</div>
            </div>
            text    
            <div role=row>
                <div role=gridcell>gridcell 3</div>
                <div role=gridcell>gridcell 4</div>
            </div>
        </div>  
    </body> 
</html>

[jnurthen]

@accdc please move to 1.4 if you will not be able to address in 1.3