- From: Joshue O Connor - InterAccess <josh@interaccess.ie>
- Date: Mon, 21 Jan 2019 09:18:01 +0000
- To: John Foliot <john.foliot@deque.com>
- CC: David MacDonald <david100@sympatico.ca>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <5C458E49.3080100@interaccess.ie>
John Foliot wrote: > [...] > > Returning to my statement, I'd never "recommend" a page or other > marked-up content use this technique today (due to the lack of real > support), I disagree John. For this SC to either get an traction or to have any hope of same, it will have to start being implemented and used. If not this SC is abstract and aspirational. Thanks Josh > but I'd also come-up short in actually "failing" the page or content > *IF* all of the technical requirements are met, specifically: "The > content is *implemented *using technologies *with support for > identifying the expected meaning* for form input data. > <https://www.w3.org/TR/WCAG21/#identify-input-purpose>" Like it or > not, Microdata, when implemented, *DOES* support the ability to > identify the expected meaning. Today, I will suggest, it's not just > being leveraged in a way that is consistently useful in our context of > assisting PwD, but I do not believe we could fail it (from a legal > conformance reporting perspective). > > JF > > On Sat, Jan 19, 2019 at 11:05 AM David MacDonald > <david100@sympatico.ca <mailto:david100@sympatico.ca>> wrote: > > > if an organization wanted to publicly publish the taxonomy in a > more robust format (hello Schema.org), then there is no technical > reason why using, say, Microdata to achieve the goal would not be > conformant. It might not actually *DO* anything at this time (lack > of tooling), but the fairly robust if 'wordy' Microdata syntax and > mechanism would not be a fail - _IF it referenced a publicly > published taxonomy library that matched the values in Section 7._ > > I would not pass something that is not accessibility supported. > "... the Success Criteria require that something be done in the > Web content that would make it possible for assistive technologies > to successfully present the content's information to the user. " > https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head > > I understand in Silver there is a proposal to change this and to > move to a more standards based approach where everybody builds to > the standard and if the AT or Browsers don't do their part then it > still passes. But that is not WCAG, which requires that conforming > techniques work with the AT and the browsers which are depended > upon for conformance. WCAG 2.0 requires real world current benefit > to users rather than an aspirational hope that something will > happen in the future with an SC. WCAG SCs for 2.0 were not created > with the "build it and they will come" approach although this 2.1 > SC starts to hint in that direction. > > 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 18, 2019 at 1:38 PM John Foliot <john.foliot@deque.com > <mailto:john.foliot@deque.com>> wrote: > > Ha, Part 2... > > I think Josh the answer is far more nuanced than that. > > A "Failure" would be a form - scoped to the *_user _*(and not, > say to the user's family[1], or work colleagues[2]) - that had > inputs that correspond to the values identified in the chart > found in Section 7 of the WCAG 2.1 Recommendation > <https://www.w3.org/TR/WCAG21/#input-purposes>. > > The failure is when any of the corresponding 'required' inputs > do not contain a /*metadata taxonomy term* /attached to the > <input>... however the *mechanism* by which that is > accomplished cannot be specified in the Recommendation (as you > likely know), because 'techniques' are non-normative, and WCAG > leaves open the possibility of more than one potential > solution/technique. > > The testing technique then is dependent (today) on manual code > inspection, where you must examine each <input> (again, scoped > exclusively to the actual user, and on the list of required > inputs found in Section 7) to see if the taxonomy concept/term > has been _programmatically attached._ As I noted in my > previous response, today the only fully 'robust' technique > would be to use @autocomplete, but if an organization wanted > to publicly publish the taxonomy in a more robust format > (hello Schema.org), then there is no technical reason why > using, say, Microdata to achieve the goal would not be > conformant. It might not actually *DO* anything at this time > (lack of tooling), but the fairly robust if 'wordy' Microdata > syntax and mechanism would not be a fail - _IF it referenced a > publicly published taxonomy library that matched the values in > Section 7._ (Part of being machine-readable is that the > machines might need to actually look up what it is they are > reading...) > > [1] A question was posed about *booking airline tickets > for you and your family*. In that instance, the only > inputs that would require the @autocomplete values (or > other technique) would be those values associated to *YOU* > - and not to the other members of your family, for while > they may share many of the same 'responses' (i.e. > family-name... maybe, maybe-not: today's nuclear family > taking so many different forms), however those inputs are > scoped to other members of the family, AND NOT THE USER, > so there is no need to tag those additional inputs. > > > [2] A similar scenario was queried, where *a "HR" form was > collecting multiple names and address* (i.e. there may be > a total of 20 on-screen inputs labeled "Name"), but again, > because this SC is scoped to the *USER*, then potentially > only the input directly related to the user > (owner/completer of the form) would require the metadata, > as all of the other date inputs are scoped to "others". > > > And when you think about it from the "functionality of > the @autocomplete attribute", it's fairly safe to assume that > most (not all) browser configurations, _if the user has opted > to store any personal data for speedier form completion on > their local user-agent in the first place_, would liekly only > store data relate to them, and not to their family members, > neighbors or work colleagues. (Currently neither Edge nor > Internet Explorer support the @autocomplete 'functionality' in > any fashion, and in fact the most robust tool supporting the > @autocomplete tokens was the Last Pass password management tool.) > > Additionally, I think it's fairly safe to presume that public > terminals WOULD NOT have this kind of personally identifying > data stored locally on those machines, so in that scenario, > the "auto-filling" function would be disabled (or at least, > unable to deliver on the functionality, due to the lack of > stored local data). None-the-less, *OUR* *accessibility value* > is primarily that those form inputs are now tagged with extra > metadata that is machine-readable, and what and how we use > that additional information is now open to tooling (etc.) > > To be clear, while using the @autocomplete attribute solution > extends some real benefit for all users (including the target > audience that inspired this SC - COGA), the 'auto-filling' of > those inputs is but one function *facilitated by adding > specific metadata terms to inputs*. And while SC 1.3.5 is > currently only for inputs, that isn't the end of the story, > it's but Chapter 1, and hopefully we'll get more and better > tools and methods to meet the much larger goal of allowing > users to customize their UI (How? when we know the purpose and > intent of all of the visual controls on the page, we can then > "output them indifferent modalities" to meet the needs of the > end user - i.e. Personalization) > _ > HTH > > JF_ > > On Fri, Jan 18, 2019 at 5:22 AM Joshue O Connor - InterAccess > <josh@interaccess.ie <mailto:josh@interaccess.ie>> wrote: > > Hi all, > > Are we saying that a well marked up form that does not > have a HTML 5.2 autocomplete attribute (or similar) is > basically a fail of this SC? [1] > > Thanks > > [1] > https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html > > -- > Joshue O Connor > Director | InterAccess.ie > > > > -- > *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 Monday, 21 January 2019 09:19:03 UTC