Re: Dealy in "Common Purposes"

I share Gregg's concerns about the speculative nature of an SC that has no
existing AT to make use of it, which may be a good reason to go with HTML
in the SC. I'm not sure. I'm going to now share my ignorance of how this
could actually work in real life in the 2 years that this standard is
supposed to be in place for.

> how are different languages and different taxonomies being handled?

I don't know...  if it revolved around the HTML autofill list it could look
for those specific values which seems pretty straight forward.
International authors are used to using English HTML language attributes
and terms for roles, states, properties etc...

If the SC revolved around the list of purposes, as in our last draft it, in
addition to a search for those autofill attributes, it could add to the
search those keywords in the accessibility api of the ACCNAME,
ACCDESCRIPTION, VALUE, etc.. and there its starts to get a little messy,
because the internationalization thing kicks in... the ACCNAME etc... might
say "First Name" in another language, in which case the AT would have to
search for the "purposes" translated....

​>
​
how does the AT find the mapping of new terms back to the definitions in
WCAG?

​I don't know​... again if its an HTML based SC it seems pretty straight
forward, use the autofill terms.

If it uses our purposes from the last draft we could number them and maybe
something could develop which uses them for different languages.

​>​
how does AT know the format of the map?

I
​ don't know... again if it is an HTML SC then it seems straight forward...
otherwise... my guess is as good as yours... maybe schema or microdata or
COGA attributes will standardize and they could all map back to our
numbered list??
​
​> I​
t is machine readable?

A
​gain if it is an HTML SC, the answer is yes... I think the intention is
that it should be machine readable, in order to make use of the
personalization
​
​>​
how does the AT find that map?
I
​ think the AT would have to have a map of the main schemas (microdata,
schema.org, coga-attributes, HTML autofill etc...)

On the eve of our CR, I have to admit I have no real idea how this will
work, unless its limited to HTML. I've been on most calls and follow our
work closely, and am a regular contributor... That scares me, because if I
don't know the answers to these things, what are people not familiar with
our work going to do.​

I'd be more comfortable with limiting it to HTML in 2.1 and let the AT
manufacturers and developers solve these issues and develop these ATs, and
expand the SC in the next version if their work proves fruitful.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

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 Sun, Jan 14, 2018 at 12:47 PM, Gregg Vanderheiden GPII <
gregg@raisingthefloor.org> wrote:

>  perhaps restricting it to HTML?
> It appears that that is where implementations are being made using aria.
>
>
>
> by the way  Lisa — how are different languages and different taxonomies
> being handled?
>
> how does the AT find the mapping of new terms back to the definitions in
> WCAG?
>
>    - how does AT know the format of the map?
>    - it is machine readable?
>    - how does the AT find that map?
>
>
> thx
>
>
> g
>
>
> On Jan 14, 2018, at 12:35 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
> Thank you Lisa. We are trying to find a way to accept a version of 1.3.4,
> but there are too many objections in its current form so it will need to be
> changed or removed. As you know, the current thinking is to focus on the
> input control purposes so that the inputs which align with the HTML5
> autofill values.
>
> There is risk in implementing specifications that are in draft, as I’m
> sure that the User 1st team is aware, so I am hopeful that we can find a
> way forward with 1.3.4 in some form.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> akirkpat@adobe.com
> http://twitter.com/awkawk
>
> *From: *"lisa.seeman@zoho.com" <lisa.seeman@zoho.com>
> *Date: *Sunday, January 14, 2018 at 12:23
> *To: *WCAG <w3c-wai-gl@w3.org>
> *Cc: *Amihai Miron <amihai@user1st.com>
> *Subject: *Fwd: Dealy in "Common Purposes"
> *Resent-From: *WCAG <w3c-wai-gl@w3.org>
> *Resent-Date: *Sunday, January 14, 2018 at 12:22
>
> From UserFirst
> All the best ... Lisa
> ============ Forwarded message ============
> From : Amihai Miron<amihai@user1st.com>
> To : <W3c-Wai-Gl-Request@w3.org>
> Date : Sun, 14 Jan 2018 17:42:06 +0200
> Subject : Dealy in "Common Purposes"
> ============ Forwarded message ============
>
> To whom it may concern,
>
> Following User1st its partners and clients interests, in respect with WCAG
> 1.3.4 "Common Purposes", which is already in the process of development by
> various teams around the world. I am approaching you on the basis of a
> concern, due to an information we got, that there might be a delay in the
> acceptance of this section.
>
> Since we are already investing in the ARIA semantics, we would like to see
> that Common Purposes as defined in the current draft, will be adapted in
> the coming version of WCAG 2.1.
>
> Thank you,
>
> [image: mage removed by sender.]
>
> *Amihai Miron*
> CEO User1st
>
> | m: +972-584-779-084
> | f:  +972-77-318-2012 <+972%2077-318-2012>
> | w: http://www.user1st.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.user1st.com%2F&data=02%7C01%7Cakirkpat%40adobe.com%7C9bac509af821456384da08d55b738220%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636515474017359632&sdata=RhlCqj4Y3KIlJFXF8qpxh7cjOeuj6dM1rJpo7NQqHVU%3D&reserved=0>
> | Skype: amihaimiron
>
>
>
>
>
>
>
>