Re: What is a failure of 1.3.5 Identify Input Purpose?

Andrew writes:

> I can provide a video that needs captions and I can provide a webVTT
caption data file.

And, interestingly enough (as it relates to this discussion), you have more
than one way of furnishing that webVTT file: in-band or out-of-band.
In-band is when the webVTT file is included in the .mp4 wrapper, whereas
out-of-band uses the <track> element (a child of the <video> element), so a
manual search of the code/DOM looking for <track> is not a sufficient
enough technique for verifying whether a video is captioned or not.

Additionally, you could also furnish the caption file as a .ttml file
<https://www.w3.org/TR/2018/REC-ttml1-20181108/>, which today should have
broad support in browsers (Note to self: more testing is due). Yet not so
long ago (2014), according to our friends over at Level Access
<https://www.levelaccess.com/captioning-formats-for-videos/>, "Internet
Explorer 10 to date is (was? JF) the only browser that supports both TTML
and WebVTT."

What this means (to me) is, there are multiple techniques (and formats)
authors can use to meet the requirement for Captions, but not all
techniques may be supported by all browsers - certainly not in 2014, I'm
frankly not sure today.

> In response to Josh’s question, I would not say that not using
autocomplete results in an automatic failure, in part because of the “about
the user” aspect that needs to be evaluated, but also because the author
may have come up with a way to meet the SC. Maybe they have built an
extension, or implemented some new JavaScript enhancement that does the
trick, or something, but until you know that they haven’t I wouldn’t fail
the page on 1.3.5.

Precisely.

JF

On Sun, Jan 27, 2019 at 7:59 PM Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> Related to this discussion, my view is that accessibility supported does
> come into play, but I may be seeing it differently than some. Any technique
> that is being used to meet a success criterion needs to be accessibility
> supported, and that means that the technique must be able to be actually
> result in benefits for end users at the time of the evaluation.
>
>
>
> Accessibility supported has two parts as it requires that the use to be
> supported by AT and supported by user agents. If the SC is one that users
> don’t use AT to gain access then that one is satisfied and the “regular”
> user agent support comes into play.
>
>
>
> Using the captions example, I can provide a video that needs captions and
> I can provide a webVTT caption data file. There’s no AT involved in the
> display of captions in order to satisfy 1.2.2, but the user agent needs to
> display the captions in order to claim that I’ve actually satisfied the SC.
> If I provide captions in a caption format (called “webCC”, and which is
> hypothetical for this argument) that is not supported by any user agent yet
> then I can’t say that I’ve met the SC. If I then go and develop a browser
> extension that uses the WebCC format and delivers captioning for the user,
> I can make a conformance claim, but the strength of that claim will depend
> on the subjective review of how readily we can expect users to be able to
> use the user agent combination.
>
>
>
> For 1.3.5 we have a technique that satisfies the SC and for which there is
> support in some user agents, so we can claim that the technique is
> accessibility supported. Not as strongly supported as some caption formats
> in terms of different user agent combinations, but supported.
>
>
>
> In response to Josh’s question, I would not say that not using
> autocomplete results in an automatic failure, in part because of the “about
> the user” aspect that needs to be evaluated, but also because the author
> may have come up with a way to meet the SC. Maybe they have built an
> extension, or implemented some new JavaScript enhancement that does the
> trick, or something, but until you know that they haven’t I wouldn’t fail
> the page on 1.3.5.
>
>
>
> I’m not sure if I’m restating what others have said entirely, but since
> John mentioned my name these are my thoughts, hopefully they help the
> discussion rather than aggravate it…
>
>
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Head of Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
> *From: *John Foliot <john.foliot@deque.com>
> *Date: *Saturday, January 26, 2019 at 2:47 PM
> *To: *David MacDonald <david100@sympatico.ca>
> *Cc: *WCAG <w3c-wai-gl@w3.org>
> *Subject: *Re: What is a failure of 1.3.5 Identify Input Purpose?
> *Resent-From: *WCAG <w3c-wai-gl@w3.org>
> *Resent-Date: *Saturday, January 26, 2019 at 2:46 PM
>
>
>
> Hi David,
>
>
>
> FWIW, *I'm* not unsure what it means: I've been working professionally
> with WCAG 2.0 since it was published (and WCAG 1.0 before that). Are you
> suggesting I (or others) don't?
>
>
>
> More importantly, you didn't answer my question - what AT requires
> supporting here? And does ALL AT need to be supported? Or just SOME AT?
>
>
>
> Let's look at an older, existing requirement: SC 2.4.1 Bypass Blocks.
>
>
>
> Today, the "recommended technique" is to use either Landmark elements or
> Landmark roles, and I'm sure you would accept that as an acceptable
> technique  in any evaluation you performed today. For screen reader users,
> is a well supported and well known solution.
>
>
>
> Meanwhile, our colleagues over at EO WG created a collection of wonderful
> user videos, including one that features a man using a specific Assistive
> Technology device: a mouth stick. That user needs a 'mechanism' to bypass
> blocks too (especially when the alternative is to tab through the 27 flyout
> menu options that are part of a common nav bar, each and every time).
>
>
>
> Now, my question to you is, how does using Landmark elements to meet SC
> 2.4.1 provide support to that AT? And if it doesn't, then how can we accept
> that as an appropriate technique? Because that seems to be where you are
> going here. So while I can agree that Techniques require a foundation in
> practical usefulness (that can be demonstrated), I get less hung up on
> needing every solution to work for everybody... maybe some day someone will
> come up with a solution to make Landmark navigation work for mobility
> impaired users like the gentleman in that video. The world is full of
> possibilities.
>
>
>
> Additionally, I don't think a TF of this Working Group - Silver TF - will
> have any further thoughts here than most of the regular participants of the
> WG, so I am unclear why or how going to them provides any additional
> insight.
>
>
>
> Finally, with no offense to either Gregg or Loretta, neither of them have
> a direct line to the One Truth here, and if you believe chairing this WG
> confers special insights or powers, we should likely also ask Andrew, Josh,
> and Alastair too, because they are or have been in the identical role as
> well: Working Group Chairs.
>
>
>
> Discussions and decisions made a decade ago were done so with the facts
> and technologies of the day, but that was then, this is now. A lot has
> changed in our world, and today Gregg is focused on cloud-based solutions
> for users with disabilities (GPII), which will be dependent (in part) on
> the types of element metadata that SC 1.3.5 advances.
>
>
>
> Adding Landmark elements certainly benefits *some* users of *some* types
> of AT today, but clearly not all users (including users that are part of
> the key target audience: keyboard-only users), yet I personally doubt that
> Gregg or Loretta would oppose that Technique because it does not support
> Mouth Stick AT users.
>
>
>
> I see very little difference here.
>
>
>
> JF
>
> (Sent from my mobile, apologies for any spelling mistakes)
>
>
>
> On Sat, Jan 26, 2019, 6:57 AM David MacDonald <david100@sympatico.ca
> wrote:
>
> I think these are issues to bring up with Silver.
>
>
>
> If someone is unsure of what WCAG is saying in the Accessibility Supported
> requirements which are clearly written in the standard, let's bring Gregg
> Vanderheiden and Loretta into the conversation so you'll hear it from the
> editors at the time.
>
>
>
> SCs and techniques that do not depend upon AT are already passing the
> Accessbility Supported requirements because they don't depend on AT.
>
> Once however AT is required to meet the SC, then WCAG Accessibility
> Support conformance requires that there be AT that works with it.
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>
>
> On Fri, Jan 25, 2019 at 12:48 PM John Foliot <john.foliot@deque.com>
> wrote:
>
> David writes:
>
>
>
> > If there is no AT that can present it to the end user then it is not
> accessibility supported and therefore I would not pass it.
>
>
>
> What AT?
>
> What AT is required for Captions? For color contrast? For visible Tab
> Focus? Text ReFlow?
>
>
>
> Not every SC in WCAG is created exclusively for AT David, and this is
> indeed one of those SC. How you evaluate WCAG is of course up to you, but
> unless or until you can point to an AT that *should* support this SC, but
> doesn't, I'd reject that statement as over-reaching and unfounded (sorry
> brother). Do we need tooling that leverages the element-level metadata to
> make things better for our users? Absolutely! Whether that is "AT" or
> something else instead however remains to be seen. Currently, we have *one*
> technique for SC 1.3.5 that leverages existing functionality in *some*
> browsers, with no AT involved.
>
>
>
>
>
> > Regarding the example alt text with a written message baked into the
> image. I always fail alt text if it is a baked in text intended for the end
> user and not incidental text like a street sign.  How can it pass?
>
>
>
> Again, I would certainly have a chat with the content creator about that
> image and it's alt text (at the same time recognizing the limitations that
> Social Media platforms forces upon content creators). *However, the
> Normative Text does NOT state that images with burned-in text MUST echo
> that text back as part of the alt text. It simply doesn't.*  At best, we
> have a (non-normative) Techniques text
> <https://www.w3.org/TR/WCAG20-TECHS/H37.html>which states:
>
>
>
> *When an image contains words that are important to understanding the
> content, the alt text should include those words.  *
> [JF - not even a MUST, but rather a SHOULD
> <https://www.ietf.org/rfc/rfc2119.txt>... (and yes, I know that WCAG does
> not reference RFC 2119, although other W3C Recs do...)]
>
> So... while I agree wholeheartedly that the alt text that Facebook is
> auto-generating (as in my previous example) has little real value at a
> user-based, functional level, it none-the-less meets the 'legal'
> conformance requirements *as prescribed by the normative text in WCAG
> 2.1:*
>
>
>
> All non-text content <https://www.w3.org/TR/WCAG21/#dfn-non-text-content> that
> is presented to the user has a text alternative
> <https://www.w3.org/TR/WCAG21/#dfn-text-alternative> that serves the
> equivalent purpose, except for the situations listed below.
>
>
>
> (Question: if the image had a caption which provided that text, would you
> still fail it? I argue you are trying to apply a black and white judgement
> that is nuanced at the best of times.)
>
>
>
> If CanAdapt wants to fail that, you are of course free to do so (based
> upon your definition of the undefined and subjective "equivalent purpose"
> term), but I will continue to argue your interpretation is from a
> user-based perspective, and not a legal-conformance-based perspective. They
> are not the same, a point I think we can all agree on.
>
>
>
> Personally, I am always truthful and candid: "*It "technically passes"
> but it's not very helpful for the intended audience*" is (I assert) the
> correct and accurate response. Then I pivot to how to make it better.
>
>
>
> JF
>
>
>
>
>
>
>
> On Fri, Jan 25, 2019 at 5:32 AM David MacDonald <david100@sympatico.ca>
> wrote:
>
> > I/we cannot advocate for *failing *a site/page if they used a
> different, standards-based technique (such as Microdata), because we don't
> pass or fail sites based on techniques, but rather whether they have met
> the requirement (functional outcome) of the SC.
>
>
>
> If there is no AT that can present it to the end user then it is not
> accessibility supported and therefore I would not pass it.
>
> Regarding the example alt text with a written message baked into the
> image. I always fail alt text if it is a baked in text intended for the end
> user and not incidental text like a street sign.  How can it pass?
>
>
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>
>
> On Thu, Jan 24, 2019 at 1:43 PM John Foliot <john.foliot@deque.com> wrote:
>
> David writes:
>
>
>
> > I also would *not* advocate consensus for a new sufficient technique
> that doesn't have any current benefit and is purely aspirational until
> technology comes along to do something with it for the end user
>
>
>
> Nor would I David (and I don't think anyone is; I'm certainly not), but,
> by the same token, I/we cannot advocate for *failing *a site/page if they
> used a different, standards-based technique (such as Microdata), because we
> don't pass or fail sites based on techniques, but rather whether they have
> met the requirement (functional outcome) of the SC. And the functional
> outcome of SC 1.3.5 is clearly stated as:
>
>
>
> *the purpose of a form input collecting information about the user can
> be programmatically determined,*
>
>
>
> Microdata is in use today (and actually more extensively than I originally
> thought, per Schema.org, Google, Bing and Yandex), and is being used by
> search engines *BECAUSE* the value of the terms can be programmatically
> determined by the search engine algorithms. So it fits the definition.
> (Today, the definition terms for SC 1.3.5 are also - at least many of them
> - undefined at Schema.org, which is another impediment to the author. But,
> again, if an organization - Benetech perhaps? - wanted to add the
> additional terms to the Schema.org taxonomy, then it could then be
> conformant to the "letter of the law" definition of SC 1.3.5)
>
>
>
> Additionally, while I've never been a huge fan of Failure Techniques
> (because we'll never document ALL the ways an author could fail), I'd
> strongly resist any suggestion or attempt to write a Failure Technique that
> suggested using Microdata was "a failure".
>
>
>
> It's just like the following example: <img src="..." alt="picture">
>
>
>
> Now, you won't get any argument from me that the suggested alt text above
> is functionally useless to the end user. HOWEVER, you couldn't "fail" a
> site that had that as the alt text, because SC 1.1.1 simply states that "*All
> non-text content that is presented to the user has a text alternative that
> serves the equivalent purpose*" WITHOUT prescribing how valuable or
> detailed that equivalency must be. Both you and I would "have a chat" with
> the developer [sic] about 'improving' that alt text (we'd both explain the
> higher-level value of the SC requirement - i.e. "education"), but the SC
> calls for a textual equivalent, and there is one provided, so you cannot
> fail the SC.
>
>
>
> (I'll also note that this appears to be the "legal-compliance" position of
> twitter and Facebook today, with their auto-generated alt texts:
>
> [image: image.png]
>
> [screen capture of an image from Facebook, with the alt-text being exposed
> on screen. The alt text reads:
>
> "Image may contain: 1 person, meme, and text"])
>
>
>
> Same premise, same argument.
>
>
>
> JF
>
>
>
> On Thu, Jan 24, 2019 at 11:57 AM David MacDonald <david100@sympatico.ca>
> wrote:
>
> Yes the reason this technique got consensus is that it provided "some
> value" today, which is laid out in the understanding as making it easier to
> fill out fields. The technique relies on browsers that support
> autocomplete, so a company could not say "we rely on IE version x for our
> conformance statement" if they have form fields collecting info about an
> end user.
>
>
>
> I advocated consensus for this SC and the autocomplete technique not upon
> its aspirational hope, but on its current benefits. I hope there is success
> with this area and support its future.
>
>
>
> I also would *not* advocate consensus for a new sufficient technique that
> doesn't have any current benefit and is purely aspirational until
> technology comes along to do something with it for the end user, because
> that would be in violation of WCAG 2/2.1 accessibility supported normative
> requirement.
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>
>
> On Thu, Jan 24, 2019 at 10:19 AM John Foliot <john.foliot@deque.com>
> wrote:
>
> *Success Criterion 1.3.5 Identify Input Purpose (Level AA)
> <https://www.w3.org/TR/WCAG21/#identify-input-purpose>: *The purpose of
> each input field collecting information about the user can be
> programmatically determined when:
>
>
>    - The input field serves a purpose identified in the Input Purposes
>          for User Interface Components section; and
>          - The content is implemented using technologies with support for
>          identifying the expected meaning for form input data.
>
> David writes:
>
> > ...with support for identifying the expected meaning for form input
> data. [JF notes that the SC doesn't say "...and then do something with that
> information..."]
>
>
>
> Patrick writes:
>
> > ...What can be done *without AT* in terms of identifying the purpose of
> the input?
>
>
>
> From the Understanding document
> <https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html>:
>
>
>
> *The intent of this Success Criterion is to ensure that the purpose of a
> form input collecting information about the user can be programmatically
> determined, so that user agents can extract and present this purpose to
> users using different modalities. The ability to programmatically declare
> the specific kind of data expected in a particular field makes filling out
> forms easier, especially for people with cognitive disabilities.*
>
>
>
> (Which also brings us back to the scoping it to the actual user
> discussion)
>
>    - [Element + machine-readable & parsable metadata] = machine can do
>    something with the metadata based upon the value of the metadata
>    - [<input> + "purpose"] = machine "knows" (or can know) what the
>    purpose of the input is, and can potentially do something with that
>    "knowledge"
>    - [<input> + @autocomplete with fixed token value] = browsers can
>    auto-fill input values based upon which token is specified
>            (2 X independent implementations = exit criteria)
>
> As previously noted however, machines (browsers) *DO NOT* have to
> autofill the inputs for this SC to be conformant, as
>
> a) not all browsers support the 'feature' (looking at you Microsoft), and
>
> b) not all browsers are expected to be storing the corresponding values
> (public terminals, etc.) associated to the end user, and finally
>
> c) that specific functionality is not part of the SC requirements.
>
> None-the-less, *IF* the author has set the conditions, *THEN* when the
> user-configuration is set accordingly, something happens.
>
>
>
> YES, this SC has a lot of aspiration behind it, and minimal support today
> (*one* technique does "something" that benefits the end user), because it
> has been made 'machine-readable' and 'machine understandable'. But we have
> the evidence of the SC meeting it's stated goal, and we've cracked the
> chicken and egg problem by starting to have developers add metadata to
> content at the element level.
>
>
>
> Do we want it to do more? Absolutely, but we have to crawl before we can
> sprint, and we had to start somewhere. But just like WCAG CANNOT *mandate*
> the use of, say, @alt to successfully meet SC 1.1.1, here as well we cannot
> mandate the use of @autocomplete to meet this SC; and if an organization
> (and we have a few working in this space today) want to build out the
> larger tool-sets to support another valid and conformant W3C technology
> (like Microdata) to identifying the expected meaning, we cannot "forbid"
> it nor "fail" it, because *we don't fail based upon techniques, but on
> outcomes*.
>
>
>
> In the simplest of terms, the functional outcome expected here is that
> inputs are 'tagged' with appropriate metadata so that "the purpose" of the
> input can be unambiguously understood by a machine.
>
>
>
> Do we need more tooling? Absolutely! But the fact that we have enough
> robust support from tools "doing something" with the appropriately tagged
> inputs today (and not just browsers BTW, we tested password managers as
> well) because they can "...identify the expected meaning..." and then
> autofill the inputs, was the justification for this SC passing the exit
> criteria. This was discussed at length during the F2F last CSUN, when we
> ran these test sprints.
>
>
>
> JF
>
>
>
>
>
> On Wed, Jan 23, 2019 at 8:03 PM David MacDonald <david100@sympatico.ca>
> wrote:
>
> > What AT is required to support the technique for this SC? Serious
> question.
>
>
>
> What can be done without AT in terms of identifying the purpose of the
> input and doing interesting things with that purpose envisioned by COGA
> such as inserting icons, swapping out labels, etc. as per the Understanding
> doc. etc....  ?
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
>
>
> On Wed, Jan 23, 2019 at 4:57 PM Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
> On 23/01/2019 21:51, John Foliot wrote:
> > Hi David,
> >
> > What AT is required to support the technique for this SC? Serious
> question.
>
> Some AT (or UA, or UA extension) that does something meaningful with
> whatever means of adding "purpose" the author chose?
>
> Probably depends on the exact reading of what "support" really
> means/refers to in
>
> "The content is implemented using technologies with support for
> identifying the expected meaning for form input data."
>
> Support in a theoretical "well, it's exposed programmatically by the UA"
> way, or support in a "and there's some real-world, actually used UA etc
> that does something with it"?
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>
>
> --
>
> *​**John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>
>
>
>
>
> --
>
> *​**John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>
>
>
>
>
> --
>
> *​**John Foliot* | Principal Accessibility Strategist | W3C AC
> Representative
> Deque Systems - Accessibility for Good
> deque.com
>
>
>
>

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