General Questions

[JAWS-test]

I have some questions about https://w3c.github.io/accname:

• For which objects does the specification apply: only for elements with roles (like img) or also for elements without roles (like img role=presentation, span or img within button)? If the latter is true: can I also label a span oder svg element with aria-label?
• Are there any restrictions on not labeling HTML elements with ARIA labels or not labeling ARIA elements with HTML labels? (e.g. role=checkbox labeled with label for)
• If an SVG graphic has a title element: does the text content not belong to the AccName - and without title element the text content becomes the AccName?
• Where do I find the rules in the specification that a span element does not lead to a space in the AccName, but a div leads to a space?
• Why placeholder is not mentioned in the specification, but in https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation
• Can I reach step I ("Otherwise, if the current node has a Tooltip attribute, return its value") also in recursion, i.e. if the tooltip is located at a child element? At least I understand the statement in F iii b as follows ("Compute the text alternative of the current node beginning with step 2. Set the result to that text alternative."). I.e. the following link should have "test" as AccName (as the i element has)

<a href=#><i title=test></i></a>

But according to https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html it has not

[ZoeBijl]

I have some questions about https://w3c.github.io/accname:

• For which objects does the specification apply: only for elements with roles (like img) or also for elements without roles (like img role=presentation, span or img within button)? If the latter is true: can I also label a span oder svg element with aria-label?

Which ARIA attributes you can use on which elements can be found in either the ARIA specifications or in ARIA in HTML.

According to ARIA in HTML both span and svg allow use of the global ARIA attributes. aria-label is a global ARIA attribute.

According to the ARIA spec aria-label can be applied to:

All elements of the base markup except for some roles or elements that prohibit its use

If we switch back to ARIA in HTML we’ll see that the presentation-role doesn’t support the aria-label-attribute.

---

• Are there any restrictions on not labeling HTML elements with ARIA labels or not labeling ARIA elements with HTML labels? (e.g. role=checkbox labeled with label for)

Can you explain this a bit more (in German if necessary)? I’m not quite sure what you mean.

---

• If an SVG graphic has a title element: does the text content not belong to the AccName - and without title element the text content becomes the AccName?

According to the note in Step 2D in AccName:

In SVG2, the desc and title elements provide a description of their parent element.

As far as I know support for this is generally buggy tho.

---

• Where do I find the rules in the specification that a span element does not lead to a space in the AccName, but a div leads to a space?

Can you provide a test case for this?

---

• Why placeholder is not mentioned in the specification, but in https://w3c.github.io/html-aam/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation

Perhaps this was omitted because the placeholder-attribute can only be used on inputs.

@joanmarie @scottaohara can either of you answer this?

---

• Can I reach step I ("Otherwise, if the current node has a Tooltip attribute, return its value") also in recursion, i.e. if the tooltip is located at a child element? At least I understand the statement in F iii b as follows ("Compute the text alternative of the current node beginning with step 2. Set the result to that text alternative."). I.e. the following link should have "test" as AccName (as the i element has)

<a href=#><i title=test></i></a>

But according to https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html it has not

In short: no.

Note: This would be a terrible practice to provide an accessible name for an element.

Step H in the accessible name calculation reads:

Otherwise, if the current node is a descendant of an element whose Accessible Name or Accessible Description is being computed, and contains descendants, proceed to 2F.i.

So if current node is the i-element in your example and we’re calculating the name for the a-element in your example we’re told to proceed to 2F.i. Essentially we’re not allowed to use the i-element’s title-attribute to calculate the accessible name of the a-element.

---

As a general note: can I ask why you ask all of these questions? While I’m sure none of us mind answering questions about the specifications from time to time. It would be nice if we knew why we’re investing a lot of time answering your questions. As an example of this: it took me roughly an hour to look into all of your questions you posted here today. At consultancy rates the information above would’ve cost you upwards of €150 😉.

If you want to help improve the specifications you might want to look at joining one of the working groups that maintain them. If on the other hand you simply want to learn more about them it might be best to join a developer orientated forum.

---

As another aside, could you please use markdown’s link notation when posting links: [text](URL)? This would make your comments a bit easier to process.

[scottaohara]

AccName #17 was already made and contains discussion and link to the HTML AAM discussion about including placeholder and aria-placeholder attributes in the spec.

As an FYI concerning aria-label being a global attribute, it will be prohibited on elements that will map to role=generic, among others, when the concept of "naming prohibited" is published. (See listing of roles prohibited from being named in current editor's draft.)

This will mean that HTML elements such as span or div will be prohibited from receiving a name, unless their role has been modified to one that does accept a name from author.

So documents such as HTML AAM and ARIA in HTML will be updated accordingly as is alluded to in the June 27th accName change log:

Add statement allowing for the possibility of naming being prohibited on the root node. Note: This change in and of itself has no implementation impact, but it allows other specifications to optionally prohibit naming for a top-level element. Furthermore, even if this prohibition is made within a specification, that prohibition will not have any impact on calculating name from contents.

[JAWS-test]

Hi @ZoeBijl and @scottaohara
Thank you very much for your answers. This will help me to understand AccName better.

If we switch back to ARIA in HTML we’ll see that the presentation-role doesn’t support the aria-label-attribute.

I don't see that in the table. This information is not in the row with "presentation". On the contrary, I know that aria-label overrides role=presentation

user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the explicit or inherited presentation role and exposes the element as described in the accessibility API mappings for presentational objects which remain in the accessibility tree (https://w3c.github.io/aria/#presentation)

I think this is wrong (see w3c/aria#1042), but it seems to me to be like this

---

Can you provide a test case for this?

<1st element><span>1</span><span>2</span></1st element>
<2nd element><div>1</div><div>2</div></2nd element>

If the elements can be labeled by content, AccName should be "12" for the first and "1 2" for the second. This also applies to b, strong, em, mark, i, sup, sub and many others inline elements (without space) and p, section, article and many others block elements (with space). I didn't find this rule in AccName and am not sure if it is missing or if I just missed it (see also #3 and w3c/html-aam#183)

---

can I ask why you ask all of these questions?

First and foremost I want to improve AT by reporting mistakes. I can only do this if I understand what mistakes are. If the specification is inaccurate, it doesn't seem to be a bug of AT if it doesn't output something correctly.

---

Are there any restrictions on not labeling HTML elements with ARIA labels or not labeling ARIA elements with HTML labels? (e.g. role=checkbox labeled with label for)

Can you explain this a bit more (in German if necessary)? I’m not quite sure what you mean.

Can I always label an HTML element with ARIA attributes? Can I always label an ARIA element with HTML attributes?

<span role=checkbox id=1></span> <label for=1>HTML label for ARIA checkbox</label>
<div role=radiogroup aria-label="ARIA legend for HTML radiobuttons">
  <label><input type=radio> YES</label>
  <label><input type=radio> NO</label>
</div>

I'm asking because this technology mix partly leads to wrong output by the screenreader. I thought the mix of HTML and ARIA was allowed without restrictions, but I wasn't sure

---

Can I reach step I ("Otherwise, if the current node has a Tooltip attribute, return its value") also in recursion, i.e. if the tooltip is located at a child element? At least I understand the statement in F iii b as follows ("Compute the text alternative of the current node beginning with step 2. Set the result to that text alternative.").

In short: no.

Yeah, that was my mistake. Unfortunately, I didn't read the specification exactly enough at this point.

---

For which objects does the specification apply: only for elements with roles (like img) or also for elements without roles (like img role=presentation, span or img within button)? If the latter is true: can I also label a span oder svg element with aria-label?

Which ARIA attributes you can use on which elements can be found in either the ARIA specifications or in ARIA in HTML.

My first question wasn't about which elements I can label with aria-label, but about which elements the specification applies to at all? For example, I can label each element with title. If AccName is not only valid for interactive elements (as I thought before), but for all elements, then the AccName of

<i title=1></i>

should be "1". This means that if AT does not output the title attribute, this would be an error.

---

Editor note: pease add your replies to a single comment in the future. Replying to everything in separate comments is not only an annoying way to read it. But also fills people’s mailboxes.

[ZoeBijl]

@JAWS-test can you please put all your things in one comment?

If the elements can be labeled by content, AccName should be "12" for the first and "1 2" for the second.

Where does it say that in the specification? Can you link to it?

Can I always label an HTML element with ARIA attributes?

No.

Can I always label an ARIA element with HTML attributes?

No.

These things are in the name calculation as well as the various other resources Scott and myself have linked to.

Also, you can’t use numbers at the start of id values. So the ids in your example are invalid.

---

As a general note: filing issues is fine. But you are filing so many that we don’t have time to respond to all of them. And most of them are about super weird code and edge cases. Which can be a good thing. But right now most of this isn’t really helping us. Specifications generally specify what should be done—not what shouldn’t be done.

If you want to help us there are a few things that need to change:

First we need live code examples and test results. This means having something like a codepen with a test case and results for which browsers and AT (including version) you tested with. Then we’d like to know what exactly is wrong with which part of the specification (and which).

Secondly we would prefer if you didn’t open three separate issues for what is essentially one bug report. Most accessibility related spec editors know each other and will contact each other when a good bug is reported. You reporting (essentially) the same bug in three different places probably means that three different people will have to invest time into the same thing. All in all this slows us down massively. When you file a bug in one place we can generally take it from there and file bugs in the relevant places when needed.

We appreciate your enthusiasm in improving assistive technologies. And we’d like to harness that enthusiasm to do something productive. The way things are going right now are not productive. Is there another way we can contact you outside of GitHub? Because this isn’t really the right venue for this discussion.

[scottaohara]

adding a bit more context, which continues my previous point in this thread and expands on a bit of what Zoë mentioned:

An HTML label cannot provide an ARIA role an accessible name. HTML attributes like alt are only valid on img and input type=image, so if you tried to use that on a div role=img it likely would not work because alt on a div is not allowed in HTML. That said, a title being a global attribute could (and should) provide a div role=textbox with an accessible name.

ARIA can label (many) HTML elements, but as noted before, there are also many HTML elements that will map to a "generic" role, and that role, among others defined in ARIA, will be prohibited from receiving an accessible name. This means that your example of <i title=1></i> would not (and should not) receive an accessible name from the title attribute, as i is exposed as static text, and thus the element is represented by its subtree. If you needed to provide an i with an accessible name you would (and again, should) also provide the element with an appropriate role that would make sense to be named.

At this point, it seems to me that we've answered these general questions, so I am closing this issue as its more of a discussion topic than having action items at this point.