Meet 1.3.5 via name attributes mapping to schema.org?

[detlevhfischer]

Hi,
The Intent section of understanding text of 1.3.5: Identify Input Purpose ends by saying

"When the user agent and assistive technology support for other metadata formats matures, metadata schemes like the Personalization Semantics Content Module may be used in addition or instead of the HTML autocomplete attribute"

We are debating whether using schema.org name attributes such as name="userFirstname", name="userLastname". name="userMail" or name="userPassword" would count as an acceptable metadata format to meet 1.3.5. Any thoughts?

[patrickhlauke]

since there's no support (as in "something that actually has a tangible effect") for anything other than autocomplete (and there, the support is "coincidental" as it's piggybacking off of an existing different attribute), i'd say no.

could AT, extensions, user scripts do something with schema.org data? sure. but there's nothing that currently does (at least with autocomplete you get password/identity management in browsers)

[detlevhfischer]

I would like to get a wider review of the WG position regarding meeting 1.3.5 via alternative taxonomies like schema.org and have therefore added the "Ready for survey" label.

My (not the WG's) proposed answer would be
"Since there is no particular requirement in th eSC text for using autocomplete to meet 1.3.5, other taxonomies such as schema.org that allow the unambiguous mark-up of particular types of inputs can also be used to meet 1.3.5 if there is sufficient accessibility support in the targeted accessibility baseline."

[detlevhfischer]

@patrickhlauke

at least with autocomplete you get password/identity management in browsers

But this is not the focus of 1.3.5 though - so one could argue that any new AT looking at input purpose could just as well check for schema.org values (perhaps as a cascade: "Is there a releant autocomplete value? If not, is there an appropriate schema.org value?") @johnfoliot ?

[patrickhlauke]

i could implement my own patrick.org metadata attribute and call it good then. because AT could look at that value too if they wanted to...

so theoretically, anything that you can claim can be used to "programmatically determine" the purpose of an input would be valid.

however, you have to weigh it up against being "accessibility supported". as far as i know, no browser nor AT does anything when encountering schema.org stuff (and sadly, same for patrick.org metadata). while autocomplete at least has some kind of tangible effect, though yes you're right it's more of a side effect and not the actual focus of the SC itself.

[patrickhlauke]

and this goes back to the chicken/egg problem of this SC, where here however we're punishing authors with a fail for not going for the chicken (or the egg) in a speculative hope that it will then be supported at some point...

unless yes, we ignore "accessibility supported" in this case and go purely by the "is it programmatically determinable", which would then allow even made-up custom metadata schemes etc to be allowed...as long as something is exposed somehow (in accessibility tree, or even just in the DOM) that can be used to identify purpose, an author could say it's a pass...

[johnfoliot]

Hi Detlev, You are correct in your reading / understanding regarding the interpretation of SC 1.3.5. In fact, when this SC was still being developed, I spent a fair bit of time and effort looking at Schema.org values <https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit#gid=1097726724> (up to and including how to add new values to the existing taxonomy). However, at that time, adding new taxonomy terms to a separate effort was outside of the scope of the AG WG, and so we had to settle with leveraging an existing taxonomy, which the token values of @autocomplete nicely met the requirement. It is not an accident however that we replicated those terms/values in our spec as well, to avoid an external dependency. Revisiting the language of the spec, it states: The purpose of each input field collecting information about the user can be programmatically determined <https://www.w3.org/TR/WCAG21/#dfn-programmatically-determinable> when: - The input field serves a purpose identified in the Input Purposes for User Interface Components section <https://www.w3.org/TR/WCAG21/#input-purposes>; and - The content is implemented using technologies with support for identifying the expected meaning for form input data. Thus, your proposal is, at least in part, technically feasible and correct. You wrote: "Since there is no particular requirement in the SC text for using autocomplete to meet 1.3.5, [JF: Correct] ...other taxonomies such as schema.org that allow the unambiguous mark-up of particular types of inputs can also be used to meet 1.3.5 [JF: Correct - see also https://w3c.github.io/personalization-semantics/content/index.html#purpose-explanation - as long as "*the other taxonomy*" supports the critical values associated to this SC, then the attachment mechanism can be customized to a certain extent] ...if there is sufficient accessibility support in the targeted accessibility baseline." [JF: Correct] The final qualifier however is the most critical: as Patrick notes, there is an expectation that a tool or tools can do something useful with the additional metadata being provided. However, while hinting at some potential outcomes, the SC does not explicitly state *WHAT* the tool or tooling must do. ...so one could argue that any new AT looking at input purpose could just as well check for schema.org values (perhaps as a cascade: "Is there a relevant autocomplete value? If not, is there an appropriate schema.org value?") [JF: Correct - or at least that was the intent] Patrick writes: "... i could implement my own patrick.org metadata attribute and call it good then." Well... yes and no (but mostly yes with enough effort). As far as creating your own metadata attribute, you can do that today using the HTML5 Custom Data Attributes (data-*) <http://html5doctor.com/html5-custom-data-attributes/>, which is the approach the Personalization Task Force is taking (by creating, amongst others, a new data-purpose <https://w3c.github.io/personalization-semantics/content/index.html#purpose-explanation> attribute now, with a desire to eventually get enough critical mass to drop the data-* part of the currently proposed attribute name - i.e. @purpose). However, for that proposal to fly, we once again need (per W3C Process), a minimum of two independent working examples, which is also being worked on (external to the TF, but in association with Lisa Seeman and at least one Israeli-based software company). Thus, if Patrick were to create a tool (or perhaps simply a browser extension) that leveraged his own custom attribute, and his own custom attribute 'accepted' or somehow supported the current existing taxonomy (aka token) values <https://www.w3.org/TR/WCAG21/#input-purposes>, **and that tool or extension had some critical mass <https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported>* , *then yes, a new *patrick.org <http://patrick.org> metadata attribute* could also pass this SC - Patrick need only supply both the Chicken *AND* the egg in that case. HTH JF

…

On Tue, Nov 26, 2019 at 11:54 AM Patrick H. Lauke ***@***.***> wrote: and this goes back to the chicken/egg problem of this SC, where here however we're punishing authors with a fail for not going for the chicken (or the egg) in a speculative hope that it will then be supported at some point... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#935?email_source=notifications&email_token=AAJL446C5C2Y26S7CFE4BWDQVVPDPA5CNFSM4JLV2TT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFG4VMA#issuecomment-558746288>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJL4432SUUKWD6KWOUU4J3QVVPDPANCNFSM4JLV2TTQ> .

-- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[patrickhlauke]

However, for that proposal to fly, we once again need (per W3C Process), a
minimum of two independent working examples

examples of what? a site using it, or a technology that does something with it? this is where the process gets murky, because any kind of custom data attribute or similar can already be "programmatically determined" in any browser, which is what the SC requires.

[johnfoliot]

Hi Patrick, So, I'll *mea culpa* and take back the actual number of "two". The current W3C Process <https://www.w3.org/2019/Process-20190301/#implementation-experience> document states: 6.2.4 Implementation Experience Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to): - is each feature of the current specification implemented, and how is this demonstrated? - are there independent interoperable implementations of the current specification? - are there implementations created by people other than the authors of the specification? - are implementations publicly deployed? - is there implementation experience at all levels of the specification's ecosystem (authoring, consuming, publishing…)? - are there reports of difficulties or problems with implementation? Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, developing tests in concert with implementation efforts. JF

…

On Tue, Nov 26, 2019 at 1:48 PM Patrick H. Lauke ***@***.***> wrote: However, for that proposal to fly, we once again need (per W3C Process), a minimum of two independent working examples examples of what? a site using it, or a technology that does something with it? this is where the process gets murky, because any kind of custom data attribute or similar can already be "programmatically determined" in any browser, which is what the SC requires. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#935?email_source=notifications&email_token=AAJL44Z77SKEVPEFP42MFPLQVV4SDA5CNFSM4JLV2TT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFHHM5Q#issuecomment-558790262>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJL44YMP6BNRRRWAWREMRDQVV4SDANCNFSM4JLV2TTQ> .

-- *​John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com

[patrickhlauke]

but again...are we talking about "sites that use it" or "there must be browsers/AT that actually do something useful with it", or ...?

because technically, any custom attribute/data attribute/etc is exposed by browsers (at least in the DOM) and can be programmatically determined. i could start using a custom data-patrick="firstname" attribute right now, and all browsers would make that programmatically available. and if i can find any 3rd party site that, for a laugh, will actually add that to their markup, i've got a "publicly deployed" use.

the reality is that autocomplete has been used as a "cheat" really to get this SC passed, because sites already used it for other things. and to this day it's the only way of implementing this that has some actual tangible effect. any other use is speculative at this point, which makes it a really hard sell to clients, other than "you just need to do it to get a pass here, we know it's pointless, but bear with us"

[patrickhlauke]

also, how is the use of autocomplete currently "accessibility supported"? it is exposed just the same way as any other attribute/data-attribute that somebody could make up. it happens to trigger the browser's autocomplete functionality/password managers can hook into it. but beyond allowing autocompletion - assuming a user has already entered their details / set up a profile for themselves in the browser/password manager - it doesn't expose/identify the purpose of fields directly to users, which is what one of the points of the SC - "user agents can extract and present this purpose to users using different modalities"

[detlevhfischer]

WCAG21 was passed nearly 1 1/2 years ago. Is anyone aware of any progress in terms of AT (browser plugin, whatever) doing anything useful with 1.3.5? I‘d love to be able to point to (non-embarrassing) examples, ill-supported as they may still be, just to be able to convince / placate clients that this is not some white elephant.