First try at ARIA role and state markup -- looking for advice

Fri Jun 15 21:30:06 UTC 2007

Interesting. So, you are thinking of the reverse (AT perspective). My guess
is that you would be looking up the parent tree looking until you found a
container role to the highest container which encompassed all the widgets
housed in siblings and descendents. Actually, in our case (app side) you
should know when (walking the parent tree) you hit the first container
since this would be outside what you markup. I am with Anastasia - it is
best to have the tool provider set the application role in this case. The
easier we can make this the better.

One thing about the discussion it seems we are advocating repair. That does
not make the developer do the right thing ( I know its philosophical).

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

             David Bolter                                                  
             <david.bolter at uto                                             
             ronto.ca>                                                  To 
             Sent by: david            Richard                             
             bolter                    Schwerdtfeger/Austin/IBM at IBMUS      
             <david.bolter at gma                                          cc 
             il.com>                   fluid-work at fluidproject.org         
                                                                   Subject 
                                       Re: First try at ARIA role and      
             06/15/2007 04:01          state markup -- looking for advice  
             PM                                                            

Hi Rich,

If any guessing (e.g. walking up containers) is involved I think it would
be great to be able to capture the "guess-ness" quality semantically.

See related discussion:
http://groups.google.com/group/mozilla.dev.accessibility/browse_thread/thread/13dc438a6a1b1288/a4f431227c858eeb#a4f431227c858eeb

cheers,
David

On 15-Jun-07, at 4:46 PM, Richard Schwerdtfeger wrote:

      Hi Anastasia,

      Your timing is impeccable. We have a number of groups looking at this
      now. SAP is asking and I have
      a call scheduled with Freedom Scientfic next week to hash out the UI
      scenarios. My response is below.

      Rich Schwerdtfeger
      Distinguished Engineer, SWG Accessibility Architect/Strategist
      Chair, IBM Accessibility Architecture Review Board
      blog: http://www.ibm.com/developerworks/blogs/page/schwer

      Anastasia Cheetham <a.cheetham at utoronto.ca> wrote on 06/15/2007
      03:33:00 PM:

      >
      > Anastasia asked:
      > > > One last question, regarding the 'application' role:
      > > >
      > > > In our case, the grid itself *is* the lightbox application, but
      our
      > > > understanding is that you can not have multiple roles. We could
      wrap
      > > > the lightbox in another div that exists just to add the
      application
      > > > role, but we're wondering if there are other options.
      >
      > Rich responded:
      > > We are still working out the interaction with the ATs. I would
      > > place "application" on the body tag.
      >
      > Hm... This is getting me thinking. Musing out loud...
      >
      > My understanding is that the purpose of the application role is to

      > tell the AT to stop operating in 'read the text' mode and to start

      > operating in 'interact with the application' mode.
      >
      > Assuming I'm right (and please correct me if I'm wrong!):
      >
      > Currently (and we expect this to be common), the lightbox is being

      > used inside a tool that is inside a portal. Which part of this
      > scenario is 'the application'? Is it the whole portal? My guess is

      > no. Is it the tool? Tools are typically application-like things, so

      > my guess is that a tool in a portal frame is an application in the

      > WAI role sense of the word. Is the lightbox itself an application?
      It
      > certainly seems to function in that sense, but if it's inside an
      > application, it doesn't seem to need the role itself.
      >
      If the lightbox is inside an application then the grid does not need
      a role
      of application - think container.

      > So it sounds like in this case, the application role should be
      > attached to the root of the tool itself.
      >
      > Given this, whose responsibility is it to set this role? The tool
      > designer?
      If the tool designer knows that an application is embedded then yes.
      Alernatively, if you knew enough about the container you could use
      script to walk the container and set the application role. I agree,
      my preference is that the tool designer should know.

      >
      > --
      > Anastasia Cheetham                   a.cheetham at utoronto.ca
      > Software Designer, Fluid Project
      > Adaptive Technology Resource Centre / University of Toronto
      >
      >    "We are at the very beginning of time for the human race.
      >     It is not unreasonable that we grapple with problems.
      >     But there are tens of thousands of years in the future.
      >     Our responsibility is to do what we can, learn what we
      >     can, improve the solutions, and pass them on."
      >                                      -- Richard Feynman
      >
      >
      >
      _______________________________________________
      fluid-work mailing list
      fluid-work at fluidproject.org
      http://fluidproject.org/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070615/c7dc38a4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070615/c7dc38a4/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic09145.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070615/c7dc38a4/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070615/c7dc38a4/attachment-0002.gif>