Rationale for span id + aria-labelledby rather than proper label?

[notabene]

Hi,

I was reading aria-placeholder (property) and was stopped in my tracks by this piece of code in the examples:

<span id="label">Birthday:</span>
<div contenteditable role="searchbox" aria-labelledby="label" aria-placeholder="MM-DD-YYYY">03-14-1879</div>

I would have expected a <label> instead of a <span id="label">. Is there a rationale behind this, or should the examples be updated as per the so-called “First Rule of ARIA”:

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.

label has faithfully and reliably acted as a label in HTML for a long time.

I would suggest simplifying the examples as follows:

<label for="birthday">Birthday:</label>
<div contenteditable id="birthday" role="searchbox" aria-placeholder="MM-DD-YYYY">03-14-1879</div>

Or perhaps this has to do with the content-editable div which is not a native form component, so for/id associations may not work.

Either way, I'd be interested to know the rationale that drove the editing team to choose this path.

[JAWS-test]

label is only allowed for native form fields.

If you check your example with https://validator.w3.org/nu you get:

Error: The value of the for attribute of the label element must be the ID of a non-hidden form control

[notabene]

@JAWS-test yes, I mentioned it on the side too, although not from a validation point of view, thank you.

I was just wondering about possible misuse or misread but inexperienced developers, along the lines of “Why should I add a label? W3C's examples don't use them” when we will ask them for accessible code.

Sadly, in my experience, some people always jump through hoops to write complex, non-compliant code when standard ways are available, tried and tested.

My suggestion didn't go all the way indeed, because I was asking for the rationale behind the way the example is formulated, it was pseudo-code. Maybe I wasn't clear enough.

[scottaohara]

@notabene I understand your concern. However, context matters here and it doesn't seem particularly out of place for the ARIA specification to provide valid examples of how one could use ARIA attributes in code.

[jnurthen]

The issue where this was added is at https://www.w3.org/WAI/PF/Group/track/actions/1349
I'm not sure it sheds any light on the example other than the fact that no one commented on the example being problematic.
Like @scottaohara I don't find use of ARIA problematic in the ARIA spec especially in an example where there is no valid HTML alternative for labelling. I hope developers in general (and especially inexperienced developers) are not referencing the ARIA spec directly but instead are using the ARIA authoring practices which are much more suited to developers.
Closing this issue. Feel free to reopen if this isn't a satisfactory response.

[notabene]

I think you're a bit too optimistic ;)

But I'm OK with your answer @jnurthen — thanks.

[jnurthen]

@notabene If you have ideas to make this more likely please let us know how we can accomplish it!

[sinabahram]

I wasn’t going to comment on this, but I’ve actually come back to it now 5 times after figuratively walking away. It really deeply bothers me that we have suboptimal code samples anywhere. We make delineations between authoring practices and the spec and so forth, but many folks, including developers, do not. I’ve observed this happen. Someone googles for it, associates a super high credibility to the result if it is from w3.org, and says, I’ll use that pattern. It’s from W3C … it can’t be wrong. It really doesn’t matter whether the above assertion is correct or not. It is one that is broadly held, I submit, so while I know this may open up an entire can of worms … I just want to say I will actually lose some sleep over this one because we just shouldn’t have code highlighted anywhere, notionally or otherwise, that isn’t an example of walking the talk. This is exactly how we have an inaccessible web in a lot of ways. Go to the Angular or React documentation, from years ago, and even in lots of cases, today, and you see tons of inaccessible or suboptimal code samples, and then those things proliferate in libraries, tutorials, internal slack messages, until they become established code dogma. I get it, the code here is not inaccessible, but still. I think there should be some overriding principle that any code snippets should be exemplary of best practices; otherwise, we’re not setting the example we want others to live up to. *shrug*, I don’t know … like I said … it’s just continuing to bother me as I go about my day. Thoughts?

[jnurthen]

@sinabahram if you want to provide a code replacement you can submit a PR.
I don't remember the discussion but this is what I infer from the code:

• We wanted an example for aria-placeholder
• we wanted an example where we couldn't use native placeholder
• we chose to use a div with contenteditable
• we decided it needed a label
• we added a label in the only way possible.

[notabene]

When I submitted the question I was in a bit of a hurry, as @JAWS-test rightfully noted (apologies) but I was thinking of something plainer like this:

<label for="birthday">Birthday:</label>
<input type="text" id="birthday" role="searchbox" aria-placeholder="MM-DD-YYYY" value="03-14-1879">

1. This is a more "atomic" example, as it only shows the one ARIA attribute the example is about.
2. It's safer for copy-paste inexperienced people (because there's a lot of that going on — I was drawn to this part of the spec by a dev who thought he could do without a label by transforming his placeholder into aria-placeholder, although we were in the middle of an issue about, well, the lack of a proper label in his code).

This does not preclude the spec from giving high-end examples somewhere else where the whole ARIA shebang is demonstrated as inspiration, I'd say.

On the other hand, if you think it's OK to keep the examples as they are, especially since they demonstrate a proper way to code a content-editable div and possibly there is no other place in the spec where you do that, I'm fine, I'm not going to grouch about it 😉 , I will just be more explicit with developers in the wild when we train/help them.

@jnurthen (you replied while I was writnig this, I'm too slow):

I don't remember the discussion but this is what I infer from the code […]

So maybe just adding a warning giving the rationale you just gave, would make me happy 😉

Thanks for listening and taking the time to respond!

[jnurthen]

@notabene with your example we would get complaints about why we are not just using native HTML placeholder
If someone wants to create a PR go ahead and if we think it makes the spec better we will include it. I'm not going to be prioritizing this though.

[notabene]

OK, I didn't want to do a PR without discussing it with you all. I'll do it, thanks.

[carmacleod]

Note that ARIA 1.3 will introduce the label role with encapsulation for certain roles (searchbox included).
The example could then be rewritten (assuming timely support from browsers) as something like:

<span role="label">
  Birthday: 
  <span contenteditable role="searchbox" aria-placeholder="MM-DD-YYYY">03-14-1879</span>
</span>

[JAWS-test]

The whole discussion made me think that it might be useful to make a distinction in ARIA spec or APG between useful ARIA roles/attributes and ARIA roles/attributes that should rather not be used because there are equivalent native HTML elements that work more reliably.

In my opinion, useful are (because they enrich and improve HTML) e.g.

• menu, menu item, menu bar
• tab, tablist, tab panel
• aria-current, aria-expanded, aria-haspopup, aria-live
• and many more

Rather should not be used (according to the first rule):

• link
• button
• textbox
• aria-hidden
• and many more

[carmacleod]

@JAWS-test @sinabahram

Regarding the "First Rule of ARIA/use semantic HTML" discussion...

Please see APG issue w3c/aria-practices#633 (which I opened, and would love to provide a PR for if I had boundless time... 😄 ).

Also, please see APG issue w3c/aria-practices#1228 (which I am also on the hook for... :)

It may make more sense to have this type of guidance in the Guide, so that the spec is free to have a few oddly-coded examples as needed to show valid ARIA use?

That said, having a little note such as the one in @notabene's PR #1170 wouldn't hurt the spec any, and might even be useful as a gentle reminder to less experienced developers.