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

[Richard Schwerdtfeger]

Hi Joseph,

Container can be a document part that updates dynamically. For example. you
could have a Region that has updated basketball scores. Within the region
you could have a dynamically updated table with no interaction vehicle
( you don't navigate it like a spreadsheet as it is a table). You would
want to browse that section like a document and let the region come up as
part of the web page summary by an assistive technology.

ARIA is divided into widgets and structural units. "Widget" is what I
believe you call a "UI Component." Some elements in the taxonomy will be a
combination of both (grid).  We will introduce an abstract "structure" role
in the taxonomy: It is not included here yet but here is an older UML
version of the taxonomy. We are working on updating this now.

(See attached file: ARIA Role Hierarchy.png)


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


                                                                           
             Joseph                                                        
             Scheuhammer                                                   
             <clown at utoronto.c                                          To 
             a>                        Richard                             
                                       Schwerdtfeger/Austin/IBM at IBMUS      
             06/18/2007 11:32                                           cc 
             AM                        fluid-work at fluidproject.org         
                                                                   Subject 
                                       Re: First try at ARIA role and      
                                       state markup -- looking for advice  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Anastasia wrote:
> 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.
>

Rich replied:
> If the lightbox is inside an application then the grid does not need a
> role
> of application - think container.

Declaring the lightbox as a container makes sense.  However, here is
another wrinkle.  Ideally, the lightbox is a standalone..."component"
(for lack of a better term) that can be used anywhere.  As Anastasia
says, it will be used as part of some greater tool/application/whole,
and is unlikely ever to stand by itself entirely.

My question then is:  are containers always thought of as a set of
"components" within an application?  Or, can containers also be used as
document parts?  I know, I should answer this myself by reading the
draft specs, but I thought I would just put it out there.  Another way
of putting it:  is their anything in ARIA that describes something as a
"component", in the sense of a UI unit that may (or may not) contain
other UI units?

--
;;;;joseph

'Was it a car or a cat I saw?'
  - "Bob", W. A. Yankovic -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070618/c77f2341/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/20070618/c77f2341/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic30326.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070618/c77f2341/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/20070618/c77f2341/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ARIA Role Hierarchy.png
Type: image/png
Size: 58879 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070618/c77f2341/attachment.png>