Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meet 1.3.5 via name attributes mapping to schema.org? #935

Closed
detlevhfischer opened this issue Nov 11, 2019 · 27 comments
Closed

Meet 1.3.5 via name attributes mapping to schema.org? #935

detlevhfischer opened this issue Nov 11, 2019 · 27 comments

Comments

@detlevhfischer
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Member

patrickhlauke commented Nov 26, 2019

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
Copy link

johnfoliot commented Nov 26, 2019 via email

@patrickhlauke
Copy link
Member

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
Copy link

johnfoliot commented Nov 26, 2019 via email

@patrickhlauke
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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.

@johnfoliot
Copy link

johnfoliot commented Nov 26, 2019 via email

@patrickhlauke
Copy link
Member

I'll point out that the reason why @autocomplete works today is because
of the attaching of element level metadata to the appropriate inputs - the
only current example of an attribute adding this granular a form of
metadata to "HTML page content" we have.

any attribute, even invented ones, would add exposed metadata to an element. it can be queried, and is programmatically exposed, the same way as autocomplete for instance. the latter just happens to also trigger some unrelated separate behavior. or are we saying the the autocomplete functionality that the attribute provides is one way that "user agents can extract and present this purpose to users using different modalities"? if so, it's probably currently also the ONLY approach that has any tangible result.

but if we're saying that the tangible result part isn't really needed to comply, then any other attribute (standardised or invented) that can provide some semantics (from a vocabulary that's either "standardised" or invented) would also work, as browsers expose them regardless.

"user agents" = more than just the browser: it's the full
stack, including OS, browser, assistive technology and other helper
applications

how is autocomplete currently supported by the full stack? it triggers browser behavior, and can be hooked into tools like 1password when they run as extensions in the browser. nothing more.

And the active verb in that sentence is 'can'

so once again, any arbitrary attribute 'can' be used the same way that autocomplete can, then?

this is turning slightly circular...

@patrickhlauke
Copy link
Member

patrickhlauke commented Nov 26, 2019

anyway, getting back to detlev's original question ... i'd still say that to just satisfy the "programmatically determined" part, any attribute/metadata approach would do. but taking the "accessibility supported" aspect as "it needs to actually do something" in a very vague sense, only autocomplete today actually does something and is the only way to legitimately pass this SC (because as soon as you argue that "but they could use schema.org even though nothing does anything with it YET" you can also claim any other attribute or made-up vocabulary is equally valid "even though nothing does anything with it YET")

@aardrian
Copy link

Tangentially, WHATWG is looking at a more internationalized list of autocomplete values:
whatwg/html#4986

Even more tangentially, this reminds me a bit of <html lang="en-US-x-Hixie">, which was technically correct (the best kind of correct), but ultimately meaningless to everyone but the guy who coded it and a time waster as a result.

Either way, I would not consider schema.org values sufficient for the same reason as Pat's point above.

@johnfoliot
Copy link

johnfoliot commented Nov 26, 2019 via email

@patrickhlauke
Copy link
Member

I fear his negativity to this particular SC is
hurting rather than helping the intended audience, simply because of the
lack of robust tooling today.

the lack of robust ... anything ... that does anything useful with the metadata

(I'll also note that the use of is also technically
correct, and ALSO a "waste of time" (at least today), as I am unaware of
any screen reader of other AT making use of the distinction between EN-US
and, say EN-CA or EN-GB

but we don't FAIL sites that don't use it despite it not doing anything...

@jake-abma
Copy link
Contributor

jake-abma commented Dec 2, 2019

Going back in time and answering Detlevs question: YES, schema.org name attributes would count as an acceptable metadata format, that is what has been said all along the creation of this SC.

But according to the comments of this issue, my question here also was and still is (and many others) the exact reason of why this SC passed in the first place and how to interpret the rules of success for a SC.

Focussing on "accessibility supported", is that the theoretical possibility of what can be done in certain circumstances OR a factual practicality existing today? (UA support + AT support!)

What if, in the case of 1.3.5, not one AT ever will implement the help needed according to the intent? Why would this fail every site today if not implemented correct?

Maybe I've misread, not understood "accessibility supported" properly and need to read it again, but without AT support (yet) isn't it NOT accessibility supported"?

At: https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head I see the following text:

When new technologies are introduced, two things must happen in order for people using assistive technologies to be able to access them.

First, the technologies must be designed in a way that user agents including assistive technologies COULD (?!) access all the information they need to present the content to the user.

Secondly, the user agents and assistive technologies may need to be redesigned (?!) or modified to be able to actually work with these new technologies.

"Accessibility Supported" means that both of these have been done (!!) and that the technology will work (!!) with user agents and assistive technologies.

I see here: and that the technology will work WITH user agents AND assistive technologies

This is not the case with 1.3.5?!

and:

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

  1. The way that the Web content technology is used MUST be supported by users' assistive technology (AT).
  2. The Web content technology MUST have accessibility-supported user agents that are available to users.

Also here you can read it as MUST be supported by AT, if no AT supports it right now, how can this pass (also for future SCs relying on NON EXISTING AT support at the time).

Bottom line: would be great to have a mutual understanding of what this means.

A: No AT + UA support present = No pass (not accessibility supported?)
B: No AT + UA support present = Pass, because in theory it could be done (accessibility supported?)

@JAWS-test
Copy link

In the understanding for 1.3.5 two use cases are explained:

  • Visual personalization ("For example, assistive technologies may display familiar icons next to input fields to help users who have difficulties reading")
  • Autocomplete function ("browsers and other user-agents can suggest and 'autofill' the right content by autocompleting these fields based on past user input stored in the browser")

Visual personalization

There is currently no UA or AT that has implemented this to my knowledge. However, it is already possible with user styles or bookmarklets. The method (autocomplete, schema.org) does not matter. The only important thing is that there is a standard here, because otherwise the user does not know which method to use. Currently, the WCAG standard only seems to be autocomplete.

autocomplete function

My tests have shown that in Chrome, Firefox, and IE 11, the autocomplete attribute and schema.org attributes have no effect. Only the attributes id and name are relevant.

@jake-abma
Copy link
Contributor

jake-abma commented Dec 4, 2019

Conformance claims say: https://www.w3.org/TR/WCAG21/#conformance

Finally, it describes what it means to be accessibility supported, since only accessibility-supported ways of using technologies can be relied upon for conformance.

Accessibility Supported says: https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported

supported by users' assistive technologies as well as the accessibility features in browsers and other user agents

NOT "it can be supported by users' assistive technologies" (IF implemented)

So, on basis of these two can I make a statement that you can never conform with WCAG 2.1 as 1.3.5 is NOT supported by AT at the moment?

(and thus, without existing support a SC MUST never be approved?!)

@jake-abma
Copy link
Contributor

https://www.w3.org/WAI/WCAG21/Understanding/conformance#programmatically-determined

In order for something to meet a Success Criterion that requires it to be "programmatically determined," it would need to be implemented using a technology that has assistive technology support.

If existing assistive technologies cannot do this, then the information cannot be said to be programmatically determined.

So what does this mean: " If existing assistive technologies cannot do this"? As in can not do it right now already OR with effort of changing the AT only then it might be possible and thus pass. (will not everything pass as software might change in a way everything might be possible in future?)

@jake-abma
Copy link
Contributor

jake-abma commented Dec 4, 2019

The only conclusion I can make after the digestion of the WCAG documents is that:

The technologies used must be able to be "reached" by an AT, like AT reaching HTML and its attributes, CSS files, A11Y API's etc.

Whatever is added to these technologies doesn't matter, schema.org, Patricks tags, my HTML comments in a weird language, as long as AT can "reach" something, all if fine and we can make criteria for not yet existing ways of communicating info / not supported by any AT.

If so, the HTML 5.2 Autofill field section was also not really needed.

@mraccess77
Copy link

@jake-abma wrote "The technologies used must be able to be "reached" by an AT, like AT reaching HTML and its attributes, CSS files, A11Y API's etc."

I disagree with that. That would mean I could expose elements accessible name through the data-jon-acc-name attribute and pass and I could use the data-jon-acc-role attribute to expose the role of my controls such as "foo" and just assume that assistive technology can get this information and communicate it as the accessible name and role. Would we allow the name attribute be used to provide the accessible name for an input field?

@jake-abma
Copy link
Contributor

@mraccess77 I agree with you also, but if so, then it makes the other comments valid? And if that view is valid?

#935 (comment)
#935 (comment)

That will, in its turn, make WCAG compliance not possible?

Struggling dearly with this issue on where we exactly place the boundaries or leave it so open to interpretation that objectivity will fail.

@alastc
Copy link
Contributor

alastc commented Aug 5, 2020

Yesterday the group agreed with this reponse to Detlev's question:

Since there is no particular requirement in the SC 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.

Picking up on Jake's comments (from my personal point of view), during 2.1 there were a couple of implementations for adding icons, but crucually, the auto-filling-in of inputs was also deemed 'enough' for the SC. There are plenty of popular implementations of that (e.g. lastpass).

So regardless of personalisation aspects, there are implementations for autocomplete, which is why I wouldn't consider schema.org to have sufficient support at this time.

@patrickhlauke
Copy link
Member

just to clarify/expand, assume that by

there are implementations for autocomplete

you mean

there are implementations that use the autocomplete attribute as a programmatically determinable hint about the purpose of an input

(i.e. we're not talking about the implementation/effect of autocompleting/autofilling per se, but the fact that the implementations take the hint from that attribute)

@alastc
Copy link
Contributor

alastc commented Aug 5, 2020

Yep, there are implementations that use the autocomplete in a benificial way (reducing cognitive load).

As we have a group agreed response I'll close this, but re-open if there is something else on the same topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants