Concern with 1.3.4 Purpose of Controls

[mbgower]

There is a fundamental issue with the SC. I agree that the NAME attribute for form elements provides a potential for incorporation of a metadata standard into existing html elements as a mechanism to introduce a way to programmatically determine the 'conventional' values for the NAME attribute (and also for the TYPE in HTML5 for some fields). However, providing conventional values for metadata is not the same as mapping that metadata to an agreed on common name vocabulary. So the description of what the SC can accomplish ("the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined") is inaccurate. At best, the SC is providing the conventional purpose, not name.
As outlined in a separate Issue, the attempt to provision both a metadata standard and a mapping to common terms as part of a glossary definition is very concerning.
Additionally, there is no equivalent existing mechanism for introducing such metadata vocabulary into links (which have at best a few options using the REL attribute) or buttons. Instead, these elements largely rely on an onscreen text string to offer any possibility of a ‘conventional name’. Relying on a text string offers significant complications for internationalization, business rules or even author tone.

[johnfoliot]

At best, the SC is providing the conventional purpose, not name.

Hmmm... I think I see where the problem lies. The current SC states:

• In content implemented using markup languages, the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.

@mbgower would an edit such as this address the concern?

• In content implemented using markup languages, the conventional name intended purpose of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.

Additionally, there is no equivalent existing mechanism for introducing such metadata vocabulary into links

As noted in my response to #426, this assertion is incorrect.

[mbgower]

@johnfoliot provided considerable concrete and constructive feedback on a number of details I tried to address above in another issue thread. He covers several broad areas:

• the availability and present state of metadata taxonomy (i.e., keywords)
• incorporating taxonomy into markup language -- as attributes of elements
• demonstrating benefit

I think he identifies progress in these areas, as well as making it clear that all the pieces are not already in place to support the SC in its current form. With less than 2 months to CR, I think it's time to re-examine the language in the SC to see how it can be modified to support what is available.

Something only peripherally touched on by John is the mapping of the metadata to a vocabulary, which I think is a central weakness of the SC as currently proposed. This is the wording of the SC:

In content implemented using markup languages, the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.

So although the title of the SC focuses on "purpose", the text is focused on "names" and the notion that conventions for these name exist. For buttons and links, the wording of the definitions strongly suggests that these names are the label values.

Such a supposition also seems to be envisioned by John's comments:

now that I have a collection of fixed and stable text-string(s) being added to the DOM

I hope I'm misunderstanding, because I can guarantee you that if we try to dictate the actual labels that every website in the world has to use for a control, you will not get adoption. The metadata is standardized. It provides the ability for a user (via a chosen tool) to override the author-assigned labels and replace them with whatever terminology they desire (in whatever language). That is the scalable model.

What if the wording was something like this:

In content implemented using markup languages, form fields, controls and links that serve a conventional purpose can be programmatically determined.

This is still a potentially large row for a development team to hoe, but at least the SC is no longer appearing to dictate UI labelling.

[mbgower]

@mbgower would an edit such as this address the concern?

@johnfoliot Sorry, I came back from dinner and posted the one I'd been working on prior to your latest comment; yes, I believe your touching on what a key concern is with your rejigged wording. It's pretty similar to what I just put in.

[jake-abma]

In response to @johnfoliot his comment about the wording #570 (comment) please note the possible proposal at: #486

[joshueoconnor]

Personal comment here - I prefer Johns original wording - as the crux is way of indicating purpose in some cases independently of the hook (Accessible Name) used to piggy back on - and identify that purpose. A key question for authors (and indeed for me) will be 'identifying the purpose of what - to what UA' - the Assistive Technolgy, the Browser, some plug in? I've not parsed the other thread on #468 so apologies if this is covered elsewhere.

It seems to be that some of the semantics/taxonomy needed may not need to granular - rather more like the need for a composite widget to only have an over arching label to define its role rather than lots of sub roles or purposes.

[jake-abma]

Hi @mbgower,

This SC is changed a lot (especially in wording) the last weeks and is indeed about “conventional purpose, not name” as you suggested also resulting in its new name “Identify Common Purpose”.

After these substantial changes and insight in the SC and seeing your comments here I’m wondering if they are still actual or if your concerns here are covered already.

The second part of the issue, “As outlined in a separate Issue”, is also already closed.