Thread Subject: Re: Group A: 21(c) Keyboard focus
Note
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Jim Tobias
Date: Mon, Oct 30 2006 9:10 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"
- Previous message in thread: Andrew Kirkpatrick: "Re: Group A: 21(c) Keyboard focus"
- Messages sorted by: Author | Thread | Date
> -----Original Message-----
> From: Andrew Kirkpatrick [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, October 30, 2006 10:37 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus
>
> > Allen, this is a fascinating idea. It would be possible to
> add such a
> > requirement to 508: a provision to purchase development tools that
> > support both accessible content and testing for accessible
> content.
> > Furthermore, all web, software, and content developed for federal
> > purposes could be required to use such tools.
>
> There is a whole industry that develops testing tools for
> various technologies, I don't think that it is wise to remove
> competition and innovation from that space by requiring that
> accessibility testing tools be built into development tools.
I agree, and that's why I explicitly didn't say "built in"; I said
"support". The goal is to make sure that a company selling a new tool gives
some thought to how its outputs would be evaluated for accessibility.
> I'm also concerned that the definition of "development tool"
> is increasingly hard to pin down - does every CMS need to
> include this functionality? Microsoft Word can create web
> pages from Word docs - should Word inclue this also?
What is a development tool? Important question, but one that can be
clarified with proper definitions. For example, what has the WAI experience
been?
> Testing tools are not the panacea that we'd all like them to
> be, I'm worried that too much focus on integrated testing for
> accessibility reinforces that misconception.
"Integrated" or "automated"? I'm talking about support for testing, not
building in every possible test; and there's lots of room for improvement in
non-automated testing tools without trying to force-fit a need for objective
measures.
- Next message in Thread: Hoffman, Allen: "Re: Group A: 21(c) Keyboard focus"
- Previous message in Thread: Andrew Kirkpatrick: "Re: Group A: 21(c) Keyboard focus"
WebAIM is an initiative of:
