E-mail List Archives
Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
From: John Foliot
Date: Jul 29, 2018 6:29PM
- Next message: Mallory: "Re: en-dash, dash and minus"
- Previous message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Joseph Sherman: "Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread
Hi Jared,
You've hit the problem nail directly on the head: accessibility supported.
One challenge we faced, and the reason this SC was skinnied down to JUST
form inputs (and not the other controls and components originally sought,
and noted in the spreadsheet I shared previously) was exactly this
chicken-and-egg problem: we lacked tools that could parse and act on
element level meta-data, because there is very little element level
meta-data out there to act upon. While limited in scope, @autocomplete was
the exception there, and met both the higher-level technical requirements
(a built-for-purpose attribute AND a defined taxonomy), while also
materially providing a concrete benefit to users today.
We faced a similar problem with ARIA in the earliest days: why add ARIA
attributes to your code if no tools were doing anything with it? And why
build ARIA-aware tools if there was no ARIA content to act on? If IBM (with
the foresight of Rich Schwerdtfeger) had not hired Aaron Leventhal to get
ARIA support embedded in Firefox, we'd likely have the same problem today
with ARIA.
At this time, while the corpus of web content explicitly using
@autocomplete is but a small percentage of web content in the wild, there
IS a significant enough body already, so that future tools now have content
to act upon. SC 1.3.5 will help increase the amount of forms out there
tagged with this meta-data, and by using the attribute and values as
designed by HTML5 now, it also has at least one direct benefit in browsers
today.
Hopefully companies and accessibility-aware hackers both will seize on this
opportunity to use the element level meta-data for other purposes that
benefit users. I expect (hope) to start to see browser extensions
prototyping different types of Personalization examples in the near future.
(Hint: this might be an interesting challenge for a hackathon.)
JF
On Sun, Jul 29, 2018, 6:35 PM Jared Smith < <EMAIL REMOVED> > wrote:
> Jon and John -
>
> I agree with both of you. Your explanations have helped me better see
> how this will be useful for accessibility in the future and why it
> should be advocated for today. I do still find the language of the
> success criterion a bit troublesome and I think it could be a bit of a
> hard sell to authors in cases where they can't associate adding
> @autocomplete with any clear user benefit *today*, but perhaps there
> will soon be new or better assistive technologies that will further
> utilize this to greatly improve form completion for users with
> cognitive and learning disabilities.
>
> Thanks,
>
> Jared
> > > > >
- Next message: Mallory: "Re: en-dash, dash and minus"
- Previous message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Joseph Sherman: "Re: (Title element) WAS WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread