Re: Regarding the accessible name for embedded section markup

But doesn’t 2H take over in this case?
“Otherwise, if the current node is a descendant of an element whose Accessible Name<https://www.w3.org/TR/accname-1.2/#dfn-accessible-name> or Accessible Description<https://www.w3.org/TR/accname-1.2/#dfn-accessible-description> is being computed, and contains descendants, proceed to 2F.i.”


James Nurthen (he/him)  |  Accessibility Engineer  |  Adobe  |  T 415 832 2734  |  nurthen@adobe.com



From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Date: Wednesday, December 2, 2020 at 12:42 PM
To: James Nurthen <nurthen@adobe.com>, Aaron Leventhal <aleventhal@google.com>, Dominic Mazzoni <dmazzoni@google.com>, Joanmarie Diggs <jdiggs@igalia.com>
Cc: ARIA <public-aria@w3.org>
Subject: RE: Regarding the accessible name for embedded section markup

Basically this ties into some algorithm changes a while back, where certain element roles would not be traversed as part of the naming algorithm when computing a name or description.

The core logic being that, elements that don’t support name from content should not be traversed for their content. This is what prevents Listboxes, trees, and many others from having all included content from being computed as part of a parent naming process.

Section implicitly maps to region, which doesn’t support name from content.

I think I see a way around this though. Section only maps to the region role when it has an explicit name, otherwise it acts like a div or span.

https://www.w3.org/TR/html-aria/

“section
role=region if the section element has an accessible name. Otherwise, no corresponding role.”

So, if it has no name as conveyed here, then it would be traversed like any other generic element.

Does this make sense?

Thanks,
Bryan





Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: James Nurthen <nurthen@adobe.com>
Sent: Wednesday, December 2, 2020 10:43 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Aaron Leventhal <aleventhal@google.com>; Dominic Mazzoni <dmazzoni@google.com>; Joanmarie Diggs <jdiggs@igalia.com>
Cc: ARIA <public-aria@w3.org>
Subject: Re: Regarding the accessible name for embedded section markup

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The major user agents all seem to agree on the name – and it is what I logically expected.
There are a lot of elements in the testcase – can you point to the one where you believe the spec says something different?


James Nurthen (he/him)  |  Accessibility Engineer  |  Adobe  |  T 415 832 2734  |  nurthen@adobe.com<mailto:nurthen@adobe.com>



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Date: Wednesday, December 2, 2020 at 10:28 AM
To: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>, Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>, Joanmarie Diggs <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>, James Nurthen <nurthen@adobe.com<mailto:nurthen@adobe.com>>
Cc: ARIA <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Regarding the accessible name for embedded section markup

Hi,
I was recently asked to evaluate the following markup for its accessible name, which seems to be causing false fails in some cases.

Can you tell me what you think the accessible name for this link should be? The tricky bit is that the spec says it should be something different than what is intuitively expected.

<a id="test" href="/path/">
<figure>
<div>
<img alt="" src="/path/">
</div>
</figure>
<section>
<span>Make a Plan</span>
<h3>Do something.</h3>
</section>
</a>

Thanks,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>