- From: Joshue O Connor - InterAccess <josh@interaccess.ie>
- Date: Tue, 29 Jan 2019 14:07:48 +0000
- To: Jonathan Avila <jon.avila@levelaccess.com>
- CC: John Foliot <john.foliot@deque.com>, David MacDonald <david100@sympatico.ca>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <5C505E34.50401@interaccess.ie>
Hi all, I'm going to make a vain attempt to try to sum up/conclude here. Back to the original question. A well marked up and otherwise accessible form, is a fail of this SC *only* when it contains information about the user and none of the related metadata tokens (as per what are defined in/a la autocomplete attribute). Correct? Cautious thanks. Josh Jonathan Avila wrote: > > John, I am aware of that ARIA technique but it’s not accessibility > supported except in limited situations. There is also H69 > <https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H69> with the > same issue. > > * Additionally, while a "skipnav" link solves a common problem (and > was well socialized thanks in large part to the old Section 508), > it only skips "one" block (the nav block), but does not furnish > the ability to skip to a specific region of the page (another > 'block'), so it too is limited in what it can furnish the end user. > > That’s why we would require multiple skip links to skip past repeated > blocks of content. > > Jonathan > > *From:* John Foliot <john.foliot@deque.com> > *Sent:* Monday, January 28, 2019 11:47 AM > *To:* Jonathan Avila <jon.avila@levelaccess.com> > *Cc:* David MacDonald <david100@sympatico.ca>; WCAG <w3c-wai-gl@w3.org> > *Subject:* Re: What is a failure of 1.3.5 Identify Input Purpose? > > WARNING: The sender of this email could not be validated and may not > match the person in the "From" field. > > *CAUTION:*This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender > and know the content is safe. > > Re: *2.4.1 Bypass Blocks: *A mechanism is available to bypass blocks > of content that are repeated on multiple Web pages. (Level A) > > Hi Jon, > > Yes, a "skipnav" link is still recommended for those keyboard-only > users not using a screen reader, however, there is this "How To Meet > Technique": > > *ARIA11: Using ARIA landmarks to identify regions of a page* > > */Applicability/*/ > Technologies that support Accessible Rich Internet Applications > (WAI-ARIA). > > *This technique relates to:*/ > > * /Success Criterion 1.3.1 (Info and Relationships)/ > > o /How to Meet 1.3.1 (Info and Relationships)/ > o /Understanding Success Criterion 1.3.1 (Info and Relationships)/ > > * */_Success Criterion 2.4.1 (Bypass Blocks)_/* > > o /How to Meet 2.4.1 (Bypass Blocks)/ > o /Understanding Success Criterion 2.4.1 (Bypass Blocks)/ > > / > *Description*/ > /The purpose of this technique is to provide programmatic access to > sections of a web page. Landmark roles (or "landmarks") > programmatically identify sections of a page. Landmarks help assistive > technology (AT) users orient themselves to a page and help them > navigate easily to various sections of a page. > > They also provide an easy way for users of assistive technology to > skip over blocks of content that are repeated on multiple pages and > notify them of programmatic structure of a page. For instance, if > there is a common navigation menu found on every page, landmark roles > (or "landmarks") can be used to skip over it and navigate from section > to section./ > > (source: https://www.w3.org/TR/WCAG20-TECHS/ARIA11.html) > > Additionally, while a "skipnav" link solves a common problem (and was > well socialized thanks in large part to the old Section 508), it only > skips "one" block (the nav block), but does not furnish the ability to > skip to a specific region of the page (another 'block'), so it too is > limited in what it can furnish the end user. > > Which takes us to the heart of the problem - even our existing > Techniques will potentially leave some users negatively impacted, > because in the end no two humans are the same, and our real goal is to > address users, not "checkpoints". None-the-less, in a pragmatic world, > we have to accept a little bit of water with our wine. > > Similar to SC 1.3.5, the goal of SC 2.4.1 is to ensure that those > regions can be 'programmatically identified', and that a "mechansim" > is *available* (and not "and must work for all users"). > > As AWK notes however, content creators have 2 choices: use a technique > and mechanism that has known (even if limited) support, OR, provide a > complete ecosystem that supports the functional requirement of the SC. > Today, for SC 1.3.5, the recommended technique on text inputs scoped > to the actual user is to use @autocomplete because a) it 'does > something' of benefit for some users with disabilities in browsers > that support the attribute, and b) it meets the higher-level > requirement of (to paraphrase) "tagging the element with metadata that > can then be used to present the content in different modalities". > > However, if an organization (perhaps the American Association on > Intellectual and Developmental Disabilities (AAIDD) > <https://aaidd.org> wanted to develop a complete, 'round-trip' > solution of tagged content and 'interpreting tool' (I keep thinking > about proxy servers...) then if it could be demonstrated that they > have met the functional requirement of SC 1.3.5, we couldn't "Fail" > them, because they are doing what the SC asks. > > This also relates to Jon's point about automated testing versus manual > testing, as we are testing for functional outcomes, and not applicable > techniques. > > JF > > On Mon, Jan 28, 2019 at 10:19 AM Jonathan Avila > <jon.avila@levelaccess.com <mailto:jon.avila@levelaccess.com>> wrote: > > Ø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. > > I disagree – and hope this is not the recommended technique as it > is not keyboard accessible and there isn’t sufficient browser > support without extension or AT to provide keyboard access. Skip > links continue to be the recommended method of meeting this > requirement. > > Jonathan > > *From:*John Foliot [mailto:john.foliot@deque.com > <mailto:john.foliot@deque.com>] > *Sent:* Saturday, January 26, 2019 2:45 PM > *To:* David MacDonald > *Cc:* WCAG > *Subject:* Re: What is a failure of 1.3.5 Identify Input Purpose? > > *CAUTION:*This email originated from outside of the organization. > Do not click links or open attachments unless you recognize the > sender and know the content is safe. > > 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 <mailto: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 <http://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 <mailto: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 <mailto: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 <http://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 <mailto: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.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 > <mailto: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 > <http://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 > <mailto: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 meaningfor 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 > <mailto: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 > <http://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 > <mailto: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 > <http://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 <http://deque.com/> > > > -- > > ***John Foliot* | Principal Accessibility > Strategist | W3C AC Representative > Deque Systems - Accessibility for Good > deque.com <http://deque.com/> > > > -- > > ***John Foliot* | Principal Accessibility Strategist | > W3C AC Representative > Deque Systems - Accessibility for Good > deque.com <http://deque.com/> > > > -- > > ***John Foliot* | Principal Accessibility Strategist | W3C AC > Representative > Deque Systems - Accessibility for Good > deque.com <http://deque.com/> > -- Joshue O Connor Director | InterAccess.ie
Received on Tuesday, 29 January 2019 14:08:46 UTC