Thread Subject: Re: General Issues: Browser Requirements
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: Gregg Vanderheiden
Date: Tue, Jan 09 2007 10:50 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Fratkin, Mike: "Re: General Issues: Browser Requirements"
- Previous message in thread: Peter Korn: "Re: General Issues: Browser Requirements"
- Messages sorted by: Author | Thread | Date
Agree with 1 and 2
RE 3 = in WCAG we have a provision requiring that the keyboard focus not be
trapped in any content without a pre warning.
No Keyboard Trap: If focus can be moved to content using a keyboard
interface, then focus can be moved away from that content using only a
keyboard interface, and the method for doing so is described before the
content is encountered and in a way that meets all Level 1 success criteria.
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: Tuesday, January 09, 2007 3:33 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] General Issues: Browser Requirements
> Hi Andi,
> > Some have suggested that we might want to impose some
> requirements on
> > browser. For example, if browsers provided more keyboard
> support, ATs
> > wouldn't have to and users who don't use AT would benefit.
> > Thoughts on this topic?
> Looking at keyboard navigation support in browsers, the tough
> stuff is all with content. In content, I think there are
> several issues:
> 1. Can I perform all operations in HTML content from the
> keyboard as I can from the mouse? I think the existing
> 1194.21(a) language already requires this.
> -> I can select text to copy to the clipboard; this
> requires keyboard gestures to mark the region of text, and a
> gesture to initiate the copy. One obvious way to do this is
> by implementing caret navigation in content, with Ctrl-C for copy.
> 2. Can I perform more sophisticated navigation in HTML
> content from the keyboard? I think 508 doesn't cover this.
> Frankly, I'm not sure it should.
> -> This isn't a matter of mouse equivalence - this is
> things like navigating from header to header, to subheader;
> from table cell to table cell. I certainly see the utility
> to the user for the browser to offer this functionality. I
> don't see where the enabling legislation of 508 empowers
> 508's involvement here - in requiring keyboard support for
> something that isn't offered to non-keyboard/mouse users.
> 3. How can I get into/out-of non-HTML content from the
> keyboard, how can I navigate that HTML content? This can
> only be solved technically through cooperation between
> applet/plug-in authors, and browser authors. It isnt' clear
> to me whether or what 508 should say.
> -> This is things like Java applets, Flash, ActiveX, etc.
> And it covers issues like competing keyboard gestures (who
> "owns" the keyboard for what gesture? are there "reserved"
> gestures? how does a plug-in/applet know what the "platform
> gestures" are so that it can be compatible with them?)
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
- Next message in Thread: Fratkin, Mike: "Re: General Issues: Browser Requirements"
- Previous message in Thread: Peter Korn: "Re: General Issues: Browser Requirements"