Meet 1.3.5 via name attributes mapping to schema.org? #935
Comments
|
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) |
|
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 |
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 ? |
|
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. |
|
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... |
|
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
|
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. |
|
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
|
|
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 |
|
also, how is the use of |
|
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. |
|
Hi Patrick,
So I have to take some exception to your statement "*...we know it's
pointless...*", because while that may be your opinion, others would
disagree: it isn't.
There was a time when using CSS for all sites was "pointless" due to lack
of browser support.
Did that mean we shouldn't have used CSS back then?
There was a time when using ARIA was "pointless" due to lack of browser and
screen reader support.
Did that mean we shouldn't have used ARIA back then as well?
Yes, there is a chicken and egg problem here, but attempting to solve it is
far from pointless, and I am somewhat dismayed that you are painting this
SC as a waste of time and resources.
the reality is that autocomplete has been used as a "cheat" really to get
this SC passed
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.
The fact that browsers are only doing one thing with that data today is
more a lack of imagination than anything else, and why shouldn't we be able
to re-use existing techniques and elements/attributes to advance digital
accessibility? (I'll also note that using "mainstream" techniques to
advance accessibility is a far sight easier than trying to sell specialty,
made-for-single-use attributes: attributes such as the aforementioned ARIA,
which really only benefits screen reader users).
Do we need more tooling? We do. But the lack of robust tooling today does
not make this SC pointless nor not worth pursuing.
"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" "
Indeed, and "user agents" = more than just the browser: it's the full
stack, including OS, browser, assistive technology and other helper
applications. And the active verb in that sentence is 'can' (not must), and
in fact there is nothing in the normative text that mandates this behavior
(outside of the fact that we anticipate this being one of the benefits of
this SC).
JF
…On Tue, Nov 26, 2019 at 2:07 PM Patrick H. Lauke ***@***.***> wrote:
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"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#935?email_source=notifications&email_token=AAJL44ZEEKMF6I5DBDN2R33QVV6ZXA5CNFSM4JLV2TT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFHJAGI#issuecomment-558796825>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJL4437JHZPMW46VXW52FTQVV6ZXANCNFSM4JLV2TTQ>
.
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
|
any attribute, even invented ones, would add exposed metadata to an element. it can be queried, and is programmatically exposed, the same way as 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.
how is
so once again, any arbitrary attribute 'can' be used the same way that this is turning slightly circular... |
|
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 |
|
Tangentially, WHATWG is looking at a more internationalized list of Even more tangentially, this reminds me a bit of Either way, I would not consider schema.org values sufficient for the same reason as Pat's point above. |
|
Hi Adrian,
Tangentially, WHATWG is looking at a more internationalized list of
autocomplete values:
whatwg/html#4986 <whatwg/html#4986>
...which is but one of the reasons why we explicitly captured the tokens
and definitions in WCAG 2.1. While *TODAY* they are the same as
the @autocomplete values in HTML5, should the WHAT WG add or remove
specific values, that change will have no impact on the WCAG spec. As Mike
(TM) Smith (aka @sideshowbarker) also notes, the list is big enough as it
is, and robust enough for most use-cases.
Either way, I would not consider schema.org values sufficient for the
same reason as Pat's point above.
Then respectfully, I suspect you are missing the point of this SC, which is
about attaching metadata to the most nuclear of page components - the
element - with a fixed, shared taxonomy, so that the purpose, use or
meaning of critical controls and components can be outputted in different
modalities (aka Personalization) to users with some forms of cognitive
disabilities. If Patrick and yourself do not believe this is the right path
forward, what do you propose instead?
The problem with using Schema.org's taxonomy today is more to do with the
facts that a) not all of the required values and definitions listed in Section
7 of WCAG 2.1 <https://www.w3.org/TR/WCAG21/#input-purposes> are defined at
Schema.org (I know, because it was my job to verify that
<https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit#gid=1097726724>),
and b) using Schema's metadata today at the element level requires
using Microdata
authoring syntax <https://www.w3.org/TR/microdata/>, which is extremely
verbose and more complicated to author. For THOSE reasons I would think
twice about using Schema.org's taxonomy, but the lack of explicit
'functionality' today is more a result of time, rather than of need.
And while I've known Patrick personally for a long time, and have a ton of
respect for him overall, 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.
(I'll also note that the use of <html lang="en-US"> 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.)
JF
…On Tue, Nov 26, 2019 at 4:49 PM Adrian Roselli ***@***.***> wrote:
Tangentially, WHATWG is looking at a more internationalized list of
autocomplete values:
whatwg/html#4986 <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
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=27799#c2> 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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#935?email_source=notifications&email_token=AAJL444Y6SOKM7BDYSNJA73QVWRXVA5CNFSM4JLV2TT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFHWHCY#issuecomment-558850955>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJL4443LK26JU77JO6UETDQVWRXVANCNFSM4JLV2TTQ>
.
--
*John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
|
the lack of robust ... anything ... that does anything useful with the metadata
but we don't FAIL sites that don't use it despite it not doing anything... |
|
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:
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:
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?) |
|
In the understanding for 1.3.5 two use cases are explained:
Visual personalizationThere 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 functionMy tests have shown that in Chrome, Firefox, and IE 11, the |
|
Conformance claims say: https://www.w3.org/TR/WCAG21/#conformance
Accessibility Supported says: https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported
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?!) |
|
https://www.w3.org/WAI/WCAG21/Understanding/conformance#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?) |
|
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. |
|
@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? |
|
@mraccess77 I agree with you also, but if so, then it makes the other comments valid? And if that view is valid? 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. |
|
Yesterday the group agreed with this reponse to Detlev's question:
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. |
|
just to clarify/expand, assume that by
you mean
(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) |
|
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. |
Hi,
The Intent section of understanding text of 1.3.5: Identify Input Purpose ends by saying
We are debating whether using schema.org name attributes such as
name="userFirstname",name="userLastname".name="userMail"orname="userPassword"would count as an acceptable metadata format to meet 1.3.5. Any thoughts?The text was updated successfully, but these errors were encountered: