WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Community for testing widgets

for

From: Cliff Tyllick
Date: Apr 15, 2016 11:22AM

Rob, I've been talking about building a site dedicated to just this sort of thing for quite some time. I am going to start today.

At CSUN, Job van Achterberg offered to transfer to me what turns out to be a great domain name for this purpose: practica11y.com. I'm working out the transfer.

I had wanted to get the W3C to build it, because I just can't see big corporations telling their developers to start with the site Cliff built in their search for highly accessible, usable components, but their focus was on policy statements then and is on accessibility tutorials now.

This site would be more line the mechanic's shop guide for accessibility—look up what you're trying to fix (login page, navigation tabs, carrousel), look up the manufacturer (HTML, react.js, bootstrap.js, Wordpress, Drupal), filter for other parameters, and quickly discover the details of how to do it right in your situation—not a tutorial, but a code sample or a series of steps to take and variables or settings to adjust.

Of course, there might be more than one right way. If so, you'd be able to learn more about each one and decide which best suits your needs. Jason Kiss recently went through that exercise by asking everyone about date widgets, trying them out, and seeing which worked best for him. If all those widgets had been uploaded to a site like the one I'm going to try to build, then all Jason could have done his task faster. And he could have added his observations to each widget he reviewed so the next person wouldn't have to repeat his work. Even an 8-year-old looking for the best date widget for her first website would have access to that information.

It might be the case that no perfect solution is available. If so, anyone would be able to discover that quickly and know whether they could meet their need by improving a known widget or would have to start from the beginning to create one of their own.

Make that person part of a project team, and in 10 minutes they would have discovered which of these situations they and their team faced:
' The best solution exists—in fact, we just need to make use of another feature in the Javascript we're already loading.
' One or more promising solutions are out there, but none do exactly what we need to do—at least not in a highly accessible way. To improve the most promising one will take 2 weeks. We should make this a deliverable for the next sprint, not the current one.
' Nothing like this has been done before. We need to bump this back to next quarter. We might even have to push it back to the next major release.

With that kind of information available more often, project managers might actually consider accessibility to be something they could manage, not their project's pit of doom.

I'll let you know more soon.

Cliff

Cliff Tyllick
Accessibility Coordinator
Texas Department of Aging and Disability Services
<EMAIL REMOVED>


Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Apr 15, 2016, at 8:36 AM, Robert Fentress < <EMAIL REMOVED> > wrote:
>
> Thanks, folks. Anyone else who is interested in participating, email me,
> and I'll include you. Sounds like the A11Y Project (http://a11yproject.com/)
> might have similar goals in mind, though, their decision to manage
> contributions with GitHub, Ruby, Jekyl Sass, and Markdown, may be a
> disincentive for some. I've just been putting stuff up on CodePen.
> Anyway, if you shoot me an email we'll figure something out.
>
> Best,
> Rob
>
>> On Fri, Apr 15, 2016 at 9:12 AM, Don Mauck < <EMAIL REMOVED> > wrote:
>>
>> Rob I think this is a good idea, certainly will look and find those
>> previous links you mention.
>>
>>