Absolutely we need to be clear in our materials that ARIA anti-patterns
would not satisfy this SC.....
** katie **
*Katie Haritos-Shea*
*Principal ICT Accessibility Architect *
*WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy,* *IAAP CPACC+WAS = *
*CPWA* <http://www.accessibilityassociation.org/cpwacertificants>
*Cell: **703-371-5545 <703-371-5545>** |* *ryladog@gmail.com
<ryladog@gmail.com>* *| **Oakton, VA **|* *LinkedIn Profile
<http://www.linkedin.com/in/katieharitosshea/>*
People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......
Our scars remind us of where we have been........they do not have to
dictate where we are going.
On Tue, Feb 20, 2018 at 10:03 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:
> Longer term the idea is to use the personalisation semantics, which is to
> one side of ARIA:
>
> https://www.w3.org/TR/personalization-semantics-
> content-1.0/#field-explanation
>
>
>
> E.g.
>
> <input type="text" name="fname" *aui-field="phone"*/>
>
>
>
> But that’s hot off the press (13th Feb), not sure about support yet.
>
>
>
> -Alastair
>
>
>
>
>
> *From: *Joshue O Connor - InterAccess
>
>
>
> Yeah - thanks Alastair and David. Good feedback both.
> The reason I ask is that a lot of people will think that they can add just
> add ARIA to satisfy this SC
> and in some cases, as David mentions for inputs, it may be doable but in
> others not.
>
> Good catch both about the AccName and the label - and we don't want that
> to be overridden etc.
>
> IMO We'll need to be clear in our materials about where ARIA anti-patterns
> would not satisfy this SC.
>
> Thanks
>
> Josh
>
>
>