Re: Use of ARIA to satisfy 'Identify common purpose' SC

Hi All,

>  using an author-specified description of purpose that isn’t tied to a
list of universally recognized purpose-oriented tokens won’t allow for the
substitution of user-specified symbols or text descriptions that support
customization/personalization for the end user.

Bulls-eye!! This is *EXACTLY* the point!!!

Additionally, this isn't about the Accessible Name (we really need to stop
thinking of it like that), it's the (*Accessible) Purpose* we're after.

As I noted to Jason previously, it's like "screwdriver" - that term can be
the "accessible name" for a tool, so we also understanding that the
"purpose" of that tool is to "drive screws". But, I can have a second tool,
with the "accessible name" of "screw gun", which is a different, separate
"name", but it still has the same "purpose" as the first tool - to drive
screws.

The bottom line is that what we seek is not a prose label directed at the
end user, but rather a referenceable token or snippet of metadata that
disambiguates the on-screen control to the point that machines can do
something useful with that information. Today, that requires a fixed
taxonomy, because AI today cannot figure out the commonality between
"screwdriver" and "screw gun" (Purpose = "tools for driving screws").

Alastair also notes the emergent Personalization Semantics, and the
introduction of new attributes. Personally, I have a number of grave
concerns about how this is emerging, including the fact that they appear to
be attempting to duplicate the wheel: the newly minted "aui-field"
attribute proposal takes one of a fixed number of values. That list of
values? The HTML5.x token values for autocomplete...

What they (COGA TF) are seeking then is something like this:

<input type="text" name="fname" autocomplete="tel" *aui-field="tel"*/>

(where @autocomplete benefits all users who take advantage of autofill,
while @aui-field is intended, presumably, for helper-apps to assist COGA
users. But if a tool could take the 'string' of "...autocomplete="tel"..."
and equate it to aui-field="tel" then the additional envisioned
machine-based customization/personalization could happen without requiring
the @aui-field attribute...)

>From my perspective, it's about *metadata *and *pattern matching* and a *common
taxonomy*: everything else is secondary.

Remember, the text of SC 1.3.4 states: "*The meaning of each input field
collecting information about the user can be programmatically determined...*"
- having a consistent fixed text string to 'search for' in the DOM makes
that string "programmatically determinable" to any and all software tools
(above and beyond 'just' browsers).

JF

On Tue, Feb 20, 2018 at 9:00 AM, <Brooks.Newton@thomsonreuters.com> wrote:

> I agree with David on aria-label not being a viable technique for
> supporting the “Identifying common purpose” Success Criterion.
>
>
>
> Unless I’m completely missing the point to this SC or this discussion
> (which is certainly possible), using an author-specified description of
> purpose that isn’t tied to a list of universally recognized
> purpose-oriented tokens won’t allow for the substitution of user-specified
> symbols or text descriptions that support customization/personalization for
> the end user.  How is using an aria-label value any different than
> specifying a visible text label for a control, in terms of not supporting
> the dual benefits we seek?  In my understanding, these dual benefits are:
>
> ·        supporting a content author’s autonomy of how she chooses to
> label an interface control, and
>
> ·        enabling an end user to personalize the description of the same
> control’s purpose in the browser/AT rendering of the content.
>
>
>
> Brooks
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Tuesday, February 20, 2018 8:36 AM
> *To:* Alastair Campbell
> *Cc:* Joshue O Connor - InterAccess; WCAG
> *Subject:* Re: Use of ARIA to satisfy 'Identify common purpose' SC
>
>
>
> > <div id="A widget that does x" role="region" aria-label="Useful
> description of that purpose">
>
>
>
> I don't think its viable. First off its not on a form input... but more
> importantly, assuming it was, tThe AccName should be reserved for the NAME
> so unless its identical to the purpose that would be a failure of 4.1.2 and
> 1.3.1
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_davidmacdonald100&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=SHEZLNLUSxKFwX0eTNlpcGa0CRQJe5knm5Ir0UJefio&s=xFHjtcYfA1jhXq2X8nLIKYg6aDFNHnyGzGv7KN1aIAI&e=>
>
> twitter.com/davidmacd
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_davidmacd&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=SHEZLNLUSxKFwX0eTNlpcGa0CRQJe5knm5Ir0UJefio&s=aH_IDQgbSe5XK28ahdzVsCsYyLrbZqNhHoZh79RKZ2Q&e=>
>
> GitHub
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DavidMacDonald&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=SHEZLNLUSxKFwX0eTNlpcGa0CRQJe5knm5Ir0UJefio&s=1mVIuDpzIp7ye5RpDqMB4P68G48CHt9xrN4m0P7Q2DU&e=>
>
> www.Can-Adapt.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.can-2Dadapt.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=SHEZLNLUSxKFwX0eTNlpcGa0CRQJe5knm5Ir0UJefio&s=s9aKEMgVVyNg2MAsfqL1VPe1mcJiCX5_J671neWF2rg&e=>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidmacd.com_disclaimer.html&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=SHEZLNLUSxKFwX0eTNlpcGa0CRQJe5knm5Ir0UJefio&s=82HxdzA26xud2ZeIeuzFhw1SOI24QagYcp0ft3GA1UI&e=>
>
>
>
> On Tue, Feb 20, 2018 at 5:04 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> Hi Josh,
>
>
>
> If applied to inputs (as the SC requires), that would over-ride the
> visible label, which is probably not what you intended?
>
>
>
> It would also fall afoul of the new SC “Label in name”, unless the visible
> label happened to be included.
>
>
>
> Perhaps you meant the more general “Identify purpose” at AAA?
>
>
>
> If so, I think that would be a method, but you’d have to be careful it
> wasn’t overriding the AccName. In practice, I think it would have to match
> a public vocabulary, the understanding needs a bit of fleshing out there as
> I can’t point you to one yet.
>
>
>
> There was a thought to apply general explanations to certain elements, but
> it went down the route of “programmatically determined”, so needs to be
> machine readable.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *Joshue O Connor - InterAccess
>
>
>
> Hi all,
>
> To follow on from the (very useful but long) previous thread on this.
> I've a simple question. Can we suggest the use of ARIA  labels etc
> satisfy the 'Identify Purpose' SC?
>
> Something like:
>
> <div id="A widget that does x" role="region" aria-label="Useful
> description of that purpose">
>
> Thoughts?
>
> --
> Joshue O Connor
> Director *| InterAccess.ie *
>
>
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion