RE: Access Key alternative -in the wrong place?

Lisa,

What you are using is the role information as a way of defining keyboard
navigation based on semantics. This is fine but we are not going to have a
keyboard mapping for every role we create and for some things like main
content or portlet the role is overkill. We should have an access key
element for some things and leave it up to the browser to create a keyboard
mapping  for specific role types should it want to. Those roles which are
critical for keyboard access we can require through UAAG guidelines and
possibly WCAG authoring techniques. So, at the end of the day the access
key types will be a small list with the role information used to determine
the rest of the keyboard mapping.

Also, I hope this is not intentional, but it would be good if we did not
have UB in front of things that would be W3C specific. Also, we already
have role so why are you now inserting contenttype. Lets be consistent. I
am not going to go back to the HTML working group to do a name change for
role.

Another concern that is growing for me is RDF. One of the problems we are
faced with on RDF is that NO browser supports it. Mozilla has some support
but Aaron tells me it is very much busted requiring a significant effort to
fix. He believes the resources are not there to do it. We also have a very
big disconnect now between the user agent manufacturers and the W3C. What
we are suggesting so far is within the realm of adoption but full RDF
support may tank the effort. At the end of the day the dynamic
accessibility issue is of greater concern than pushing an RDF agenda which
very likely will not pass candidate recommendation. At the moment I am the
only one in the group working with the browser manufacturers to make this
happen and I can tell you that given the current relationship with the
browser manufacturers and the W3C we may need to push this off or find an
alternative. If we feel compelled to push RDF it will probably require a
two stage approach and add it later. Also, we need to be realistic. The CR
recommendaton should based on 2 mainstream browser implementations which
matter.

I am talking to Microsoft Longhorn accessibility development next week
regarding the roadmap.

Rich


Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review  Board
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost



                                                                           
             Lisa Seeman                                                   
             <lisa@ubaccess.co                                             
             m>                                                         To 
                                       "'Jon Gunderson'"                   
             06/24/2004 02:18          <jongund@uiuc.edu>, Richard         
             AM                        Schwerdtfeger/Austin/IBM@IBMUS,     
                                       Becky Gibson/Westford/IBM@Iris      
                                                                        cc 
                                       w3c-wai-pf@w3.org, WAI-GL@w3c.org,  
                                       "'Liddy Nevile'"                    
                                       <Liddy.Nevile@motile.net>,          
                                       w3c-wai-gl@w3.org                   
                                                                   Subject 
                                       RE: Access Key alternative  -in the 
                                       wrong place?                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Something obvious hear

for links: we can save content authors a lot of time if we  attach the
type of content to the page, not the link to the page.

E.g. page level in meta data like
<meta name= pageType content="UB:siteMap">

(sorry Liddy - i havn't looked up how to do this legally)

 It can then be programmatically derived that any link to this page is a
link to the site map.
alternatively you can do it as a site wide annotation (SWAP again)



Much quicker and easer then adding access keys or defining types of
links at each usage.

Now why can't we attach DC metadata title  and description  onto all
image files in place of filling in an alt and longdesc when ever the
images are used. (alt can override the meta title if the web author is
using an image/media in a different way to how the graphic artist
anticipated the image being used)

That is why we need to design accessibility solutions from an
architectural level, and not from the html content symptom solving thing


Keep well all

Lisa


> -----Original Message-----
> From: w3c-wai-pf-request@w3.org
> [mailto:w3c-wai-pf-request@w3.org] On Behalf Of Al Gilman
> Sent: Wednesday, June 23, 2004 6:46 PM
> To: Jon Gunderson; Richard Schwerdtfeger; Becky Gibson
> Cc: w3c-wai-pf@w3.org
> Subject: Re: Access Key alternative
>
>
>
> At 9:33 AM -0500 6/23/04, Jon Gunderson wrote:
> >  >Jon, Page structure is high on my list of "Task Force Topics we
> >should
> >>have re-organized around as soon as UAAG 1.0 was done."  It
> is still
> >>out there as an important topic that takes lots of
> >cross-discussion
> >>to get it right.  Should we try to launch a task force or
> >should we
> >>do a one-shot ad-hoc meeting to see if an ongoing work package is
> >>called for?
> >
> >I think it would be good to have a meeting on this topic.
> It would be
> >nice to have some example implementations before any meeting
> to start
> >the discussion.
>
> Of course running examples help greatly.  But we can't stop
> giving our partners in the Hypertext CG advice while we wait
> for running examples.  And besides, SWAP provides a running
> example.  And Mozilla is signed up to create running examples.
>
> We have multiple Working Groups building pieces of the
> future-tech puzzle from EMMA to DISelect to XBL applications
> in styling etc.  They welcome our input on their work in
> progress.  It makes sense to review the functional design
> decisions before one can see running examples.
>
> Would you have time to join today's PF call?
>
>
> ** Calling information:
>
> 2004-06-23, 1600Z (for 90 minutes)
> Dial +1 (617) 761-6200 (This is a USA number). Zakim bridge.
> You will be prompted for a pass code, please enter 92473# (WAIPF#)
>
> During the conference you can manage your participation with Zakim
> commands as follows:
>   61# to mute yourself
>   60# to unMute yourself
>   41# to raise your hand (enter speaking queue)
>   40# to lower your hand (exit speaking queue)
>
> The system acknowledges these commands with a rapid,
> three-tone confirmation.  Mobile phone users especially
> should use the mute function if they don't have a mute
> function in their phone.  But the hand-raising function is a
> good idea for anyone not using IRC.
>
> * IRC access
>
>     There will also be an IRC channel available. The server
> is irc.w3.org,
>     the port number is 6665 (note this is not the normal
> default) and the
>     channel is #pf.
>
> The call time of 16:00 UTC, a.k.a. 16:00 Z is at
>
> 12: noon, Eastern [Daylight Time]
> 9: a.m. Pacific [Daylight Time]
> 17:00 in England [Summer Time]
> 19:00 in Israel [DST equivalent]
>
> * Time Zone Converter - time conversion
>   http://www.timezoneconverter.com/cgi-bin/tzc.tzc
>
>
> >
> >Jon
> >Jon Gunderson, Ph.D., ATP
> >Coordinator of Assistive Communication and Information Technology
> >Division of Rehabilitation - Education Services MC-574
> >College of Applied Life Studies
> >University of Illinois at Urbana/Champaign
> >1207 S. Oak Street, Champaign, IL  61820
> >
> >Voice: (217) 244-5870
> >Fax: (217) 333-0248
> >
> >E-mail: jongund@uiuc.edu
> >
> >WWW: http://cita.rehab.uiuc.edu/
> >WWW: http://www.staff.uiuc.edu/~jongund
>