Re: Using title for ARIA name is impractical!

Hi all
a few comments

>1. Quick search in Chat:

Inclusion of the label for the text input in the field itself is not
sufficient for sighted users with disabilities.
- disappears on focus
- contrast is poor (fails WCAG 2.0 luminosity test)

As i understand it ARIA best practise is to use native host language
features first - therefore use of label (visible text)  element would
be recommended. If not practical, then next best would be use of title
attribute on the input, which would at least make it more accessible
in some  user scenarios: current and future AT including screen
magnifier and screen reader users)

Use of ARIA without either of these would not make it "accessible" as
only a small number of AT users can benefit from the use of ARIA.

Therefore does not appear to be a use case for the need or appropriate
use of a new attribute such as aria-name.

Will provide feedback on the other cases cited when i get time.

-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html




2008/7/31 Srinivas Annam <annams@google.com>:
> Thanks Aaron. Loretta and I would like to join the call, can you send me the
> call details. Also, there was an ask for live use cases where usage of title
> is an issue. Here are some (from Gmail standard interface) -
>
> Quick search in Chat: This widget is visually identified with the text
> "Search, add, or invite" and is reachable via keyboard shortcut "q" (if you
> have them enabled) or by pressing TAB repetitively. As you focus into this
> widget (either by TAB or by kbd shortcut "q") the text is cleared and an
> empty input box is shown. Here the challenge for a screen reader user is
> that upon focus the text box would have been cleared and the text it
> retrieves would be empty. Currently the name is being provided with the help
> of aria-labelledby, but there may be situations where the text is set
> dynamically set using javascript and is not available for aria-labelledby.
>
> Status menu: This sits right next to status message in Tab order and is
> exposed as menu button, takes Enter key (currently no arrow key support) to
> show the status menu. Initial focus will be on the entire menu and takes up,
> down arrow keys to navigate through menu items. ARIA roles are exposed for
> the menu as well as for each menu item. (NOTE: Esc on the menu works but
> currently does not set the focus back to the status menu) Currently a title
> is being used to provide the text "Status menu" as aria name. The tooltip
> here was introduced for the specific purpose of providing aria name. One
> possible workaround is to have the initial focus on the first menu item
> (rather than on the menu) while having no aria-name on the list. This goes
> with Aaron's argument that all users should figure out what the menu is just
> like a visual would figure out -- based on the context. If any screen reader
> user can try this out and comment on it that would be very useful.
>
> Contact list: Exposed as ARIA list and is part of the tab order. Up, down
> arrow keys are supported to navigate through the menu. Pressing Enter on any
> chat takes the default action -- which is to open Chat for available or idle
> contacts and compose mail for offline contacts. Very similar use case as
> above, but any tooltip would show for the entire list and has bad
> interactions with the popup that gets shown on mouse hover.
>
> Thanks,
> Srinivas
>
> On Wed, Jul 30, 2008 at 8:05 AM, Aaron M Leventhal <aleventh@us.ibm.com>
> wrote:
>>
>> Can someone who strongly supports the idea come to one of the Monday ARIA
>> calls to advocate for it?
>>
>> - Aaron
>>
>>
>> From: "Loretta Guarino Reid" <lorettaguarino@google.com>
>> To:
>> Aaron M Leventhal/Cambridge/IBM@IBMUS
>> Cc: "Victor Tsaran" <vtsaran@yahoo-inc.com>, "Srinivas Annam"
>> <annams@google.com>, sailesh.panchang@deque.com, wai-xtech@w3.org,
>> wai-xtech-request@w3.org
>> Date: 07/26/2008 02:33 PM
>> Subject: Re: Using title for ARIA name is impractical!
>> ________________________________
>>
>>
>>
>> Aaron,
>>
>> While I agree that this needs to be thought through carefully, I
>> disagree that using hidden labels is desirable (although there are
>> situations where it may be necessary, too). Hidden labels don't
>> degrade gracefully in the absence of  CSS. We are taking advantage of
>> the current behavior of screen readers, but there is nothing inherent
>> in "hiding" text by positioning it offscreen, in contrast to hiding it
>> with various values of display, that means one should be visible to
>> assistive technology and the other shouldn't.
>>
>> I think it would be much cleaner to have a well-defined ARIA attribute
>> for the purpose of providing a name when there is no visible label,
>> for whatever reason.
>>
>> Here is another example where I think this type of support would be
>> useful: Phone numbers in the US are often represented by three fields
>> (area code, prefix, suffix). A single visual label is adequate for the
>> 3 fields, but each should have a name exposed to AT.
>>
>> Loretta
>>
>> On Sat, Jul 26, 2008 at 7:03 AM, Aaron M Leventhal <aleventh@us.ibm.com>
>> wrote:
>> >
>> > MSAA has accName and accDescription from before the days when their were
>> > relationships like labelled_by and described_by, which newer APIs like
>> > ARIA,
>> > IA2 and ATK/AT-SPI all have. It allows you to point to a real label. You
>> > also need accName to expose alt for images.
>> >
>> > I don't want to be the naysayer. I just need to think about the
>> > consequences
>> > of adding something which could be redundant with aria-name. It would be
>> > bad
>> > if authors used aria-name if there was in fact a visible label to point
>> > to.
>> > Has anyone thought of the potential for misuse?
>> >
>> > Let's make sure the pros and cons are pointed out. No one has pointed to
>> > any
>> > real world examples where this is really necessary. And, it's not like
>> > you
>> > can't do it now. It's in fact a hidden label so using a hidden label
>> > fits,
>> > right?
>> >
>> > - Aaron
>> >
>> >
>> > From: "Victor Tsaran" <vtsaran@yahoo-inc.com>
>> > To: Aaron M Leventhal/Cambridge/IBM@IBMUS, "'Srinivas Annam'"
>> > <annams@google.com>
>> > Cc:
>> > <sailesh.panchang@deque.com>, <wai-xtech@w3.org>,
>> > <wai-xtech-request@w3.org>
>> > Date: 07/26/2008 02:04 AM
>> > Subject: RE: Using title for ARIA name is impractical!
>> > ________________________________
>> >
>> >
>> > As in the desktop world, sometimes visual proximity, iconic cues are all
>> > that is needed for a sighted user to understand the context. Sooner or
>> > later
>> > we have to deal with situations where, because of the UI considerations
>> > or
>> > lack of screen real estate certain textual cues or labels are omitted.
>> > This
>> > is why I think what Sri is proposing makes sense. There should be a way
>> > to
>> > provide auxiliary information to screen readers (or any other AT, for
>> > that
>> > matter) regardless of whether it is displayed on the screen or not. For
>> > instance, the developer may want to provide additional instructions to a
>> > screen reader or go as far as overwriting the name of the widget
>> > altogether
>> > in order to make it more meaningful.
>> > Otherwise, why would MSAA have properties such as accName and
>> > accDescription?
>> > In fact, accDescription was used by some apps to provide positioning
>> > information to AT.
>> > ... Etc ...
>> >
>> >
>> > Victor
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
>> > Behalf
>> > Of Aaron M Leventhal
>> > Sent: Thursday, July 24, 2008 1:06 PM
>> > To: Srinivas Annam
>> > Cc: sailesh.panchang@deque.com; wai-xtech@w3.org;
>> > wai-xtech-request@w3.org
>> > Subject: Re: Using title for ARIA name is impractical!
>> >
>> >
>> > Sri, to answer the original question you had, ARIA isn't implementing
>> > title.
>> > The title attribute is part of HTML from a long way back.
>> > ARIA just discusses where title text fits into the general name
>> > computation
>> > algorithm. So ARIA really has nothing to do with the tooltip.
>> >
>> > But I thought the more interesting question was, should ARIA provide a
>> > more
>> > convenient mechanism than aria-labelledby to provide accessible names,
>> > like
>> > aria-name, to avoid the need for hidden labels. It's clear that the side
>> > effect for tooltip makes it undesirable for developers. I'm just not
>> > sure
>> > the use case of having special accessible names rendered only for
>> > non-sighted users is that common for widgets which are not built from
>> > images, that we need to have yet another mechanism. I was saying that
>> > something list a chat listbox that has no label for sighted users
>> > doesn't
>> > really need a special name. The screen reader will use the previously
>> > active
>> > item as the name, which is all the sighted user gets as well. In most
>> > cases
>> > we shouldn't be adding these hidden labels, IMO.
>> >
>> > - Aaron.
>> >
>> >
>> >
>> > From:                  Srinivas Annam <annams@google.com>
>> > To:                  sailesh.panchang@deque.com
>> > Cc:                  wai-xtech@w3.org, wai-xtech-request@w3.org
>> > Date:                  07/24/2008 07:25 PM
>> > Subject:                  Re: Using title for ARIA name is impractical!
>> >
>> > ________________________________
>> >
>> >
>> >
>> >
>> > On Thu, Jul 24, 2008 at 6:34 AM, Sailesh Panchang
>> > <sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com> > wrote:
>> >
>> >> that makes me ask, why do screen reader users even need a name for
>> >>something if sighted people don't have one?
>> > A list box is a UI element - a form control and it needs to be
>> > associated
>> > with a label (SC 1.3.1 of WCAG2 or checkpoint 12.4 of WCAG1). Where the
>> > design cannot accommodate a visible label, then a title attribute is
>> > typically used on the INPUT or SELECT element in HTML. In this case
>> > without
>> > a visible label a screen reader user may not realize which list box has
>> > focus. So a title is a workable substitute.
>> > The title is correctly displayed by the browser for the container and
>> > contained elements when moused over. That is the expected behavior. What
>> > is
>> > displayed against the div element is not unrelated to the options under
>> > it
>> > and may actually help more than one disability group. I checked with
>> > several
>> > colleagues here and they do not regard the tooltip display as a
>> > nightmare or
>> > as something impractical.
>> >
>> > I believe your colleagues are talking tooltips in general, not tooltips
>> > when
>> > they are expected or unwanted. As I described in my Gmail example where
>> > a
>> > popup is expected as you hover over a contact, tooltip is definitely is
>> > unwanted and impractical.
>> >
>> > By taking only simplististic cases and convincing that ARIA fully
>> > addresses
>> > those cases will create a situation where an application developer will
>> > be
>> > forced to make choices which will make ARIA web as standards-compliant
>> > as
>> > what the rest of the web is today! :(
>> >
>> > Whether we like it or not complex widgets are here to stay. We do need
>> > to
>> > consider them and provide for situations like this to grow ARIA and
>> > allow it
>> > to be used in every situation.
>> >
>> > Coming back to my original question, why is that ARIA forcing me to get
>> > the
>> > "tooltip side effect" in order for me to get an @name on these roles?
>> > Why
>> > can't I as an application developer have the choice to get the @name as
>> > I
>> > want it without showing a tooltip to the user?
>> >
>> >
>> >>If sighted users are figuring it out from context then why not screen
>> >>reader users?
>> > Sure no problem... expose the context programmatically so that  screen
>> > reading software can determine the context. That is the purpose served
>> > by
>> > these various attributes, right?
>> > Please also consider: double click to make a selection is not the
>> > convention
>> > in a list box for a mouse user.
>> > Sailesh Panchang
>> > Accessibility Services Manager (Web and Software) Deque Systems Inc.
>> > (www.deque.com <http://www.deque.com/> ) 11130 Sunrise Valley Drive,
>> > Suite
>> > #140, Reston VA 20191
>> > Phone: 703-225-0380 (ext 105)
>> > E-mail: sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com>
>> >
>> > -----Original Message-----
>> > From: Aaron Leventhal [mailto:aaronleventhal@moonset.net
>> > <mailto:aaronleventhal@moonset.net> ]
>> > Sent: Wednesday, July 23, 2008 4:40 PM
>> > To: Srinivas Annam
>> > Cc: sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com> ;
>> > wai-xtech@w3.org <mailto:wai-xtech@w3.org>
>> > Subject: Re: Using title for ARIA name is impractical!
>> >
>> > Personally I'm wavering back and forth on this one.
>> >
>> > Pro:
>> > I can see Sri's point. As a developer, if I'm writing a chat app, I
>> > might
>> > like the screen reader users to get a nice name for the listbox.
>> > It just makes the experience smoother.
>> >
>> > Con:
>> > OTOH this is one more thing to localize, so I personally might avoid it.
>> > In fact that makes me ask, why do screen reader users even need a name
>> > for
>> > something if sighted people don't have one? To me the use case of
>> > showing
>> > something to one set of users and not another is not so major.
>> > If sighted users are figuring it out from context then why not screen
>> > reader
>> > users? (There may very well be an answer for that, I just don't know it
>> > as
>> > I'm not a screen reader user myself).
>> >
>> > Also, adding aria-name does make the accessible name processing
>> > algorithm
>> > slightly more complicated.
>> >
>> > - Aaron
>> >
>> > Srinivas Annam wrote:
>> >> On Wed, Jul 23, 2008 at 12:15 PM, Sailesh Panchang<
>> >> sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com> >
>> >>  wrote:
>> >>
>> >>>   I went back to the first email and read the issue had noted:
>> >>>
>> >>> "At this time you would notice that hovering over with mouse on
>> >>> anywhere over the listbox area (including where the individual items
>> >>> are shown)
>> > would
>> >>> show a tooltip with the title. This is coming in as a side effect of
>> > browser
>> >>> usage of title for the tooltip. Given this major UI implication, IMO,
>> > this
>> >>> makes the usage of title to get an acc name on the roles mentioned
>> >>> highly impractical. I would like to hear other thoughts or ideas".
>> >>>
>> >>> Comment:
>> >>>
>> >>> The title is read  by the screen reader not while arrowing up and
>> >>> down
>> > the
>> >>> list box items but as one tabs in and out of the list box along with
>> >>> the item selected which is ok for a keyboard user.
>> >>>
>> >>> So my question is : What is impractical about the tool tip being
>> > displayed
>> >>> as one mouses over the items in a list box?
>> >>>
>> >> The tooltip is useful when you see it once, but it becomes an
>> >> annoyance
>> > when
>> >> it shows up every time you are hovering for some other reason. Going
>> >> back
>> > to
>> >> my Gmail example there is a popup that shows as hover over a single
>> > contact,
>> >> now imagine seeing two things one the hover popup you wanted and the
>> > second
>> >> is the tooltip. This is clearly a UI nightmare.
>> >>
>> >> Again, one point I am trying to make is why is that an application
>> > developer
>> >> is being forced to get the side effect of tooltip when the intent is
>> >> to provide the aria name.
>> >>
>> >>> The title attribute in HTML on the opening container tag  (even on
>> >>> FORM
>> > or
>> >>> UL or map) is displayed on all contained items if one mouses over
>> >>> them.
>> > This
>> >>> is standard behavior in IE and Firefox for a long time and no one has
>> >>> objected to this.
>> >>>
>> >>> (It is another matter that screen readers do not read title on all
>> > elements
>> >>>   and I have in the past suggested to FS and GWMicro to change this).
>> >>>
>> >>> I understand the more serious issue for a mouse user is that one has
>> >>> to double click to make a selection which is not the convention in a
>> >>> list
>> > box.
>> >>>
>> >>> Sailesh Panchang
>> >>> Accessibility Services Manager (Web and Software) Deque Systems Inc.
>> >>> (www.deque.com <http://www.deque.com/> ) 11130 Sunrise Valley Drive,
>> >>> Suite #140, Reston VA 20191
>> >>> Phone: 703-225-0380 (ext 105)
>> >>> E-mail: sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com>
>> >>>    ------------------------------
>> >>>
>> >>> *From:* wai-xtech-request@w3.org <mailto:wai-xtech-request@w3.org>
>> >>> [mailto:wai-xtech-request@w3.org <mailto:wai-xtech-request@w3.org> ]
>> >>> *On Behalf Of *Srinivas Annam
>> >>> *Sent:* Wednesday, July 23, 2008 12:53 PM
>> >>> *To:* Aaron Leventhal
>> >>> *Cc:* dev-accessibility@lists.mozilla.org
>> >>> <mailto:dev-accessibility@lists.mozilla.org> ; wai-xtech@w3.org
>> >>> <mailto:wai-xtech@w3.org>
>> >>> *Subject:* Re: Using title for ARIA name is impractical!
>> >>>
>> >>>
>> >>>
>> >>> Hi Aaron,
>> >>>
>> >>> On Wed, Jul 23, 2008 at 1:29 AM, Aaron Leventhal<
>> >>> aaronleventhal@moonset.net <mailto:aaronleventhal@moonset.net> >
>> >>>  wrote:
>> >>>
>> >>> Hi Sri,
>> >>>
>> >>> I have the idea, although I had not seen a scenario where you want
>> >>> the menu text to be different from what's shown visually yet.
>> >>>
>> >>>
>> >>> Not different, but the text is not being shown visually at all in
>> >>> these cases. Here are some scenarios -
>> >>>
>> >>>     1. You have a listbox (visually not titled), which takes focus on
>> >>>     itself and subsequently on it's list items. Provide a title on
>> >>> the
>> > listbox
>> >>>     which has the outermost div and the option items being inside.
>> >>> The
>> > title
>> >>>     provided on the listbox bleeds through as I hover over on any of
>> >>> the
>> > option
>> >>>     items. (see the modified listbox example I sent earlier)
>> >>>     2. Have a menu button (with a role of button and haspopup is set
>> >>> to
>> >>>     true), the button has it's own text and drop down arrow will show
>> >>> a
>> > popup
>> >>>     menu and set the focus to popup. Adding a title on the popup menu
>> > will
>> >>>     introduce a tooltip as I hover over any of the menu items.
>> >>>     3. Similarly a tree having the outermost div and a title. Hovering
>> >>> on
>> >>>     the tree items will show the title as tooltip.
>> >>>
>> >>> When I first encountered the issue I did not see it so much as a bug
>> >>> in
>> > the
>> >>> browser, but I do want to understand why you think it is. What is the
>> >>> expected behavior when you have a title on a div, should the tooltip
>> >>> be shown across the entire area that the div is covering or not
>> >>> (since there
>> > is
>> >>> no title for the child elements)? Would love to hear your thoughts.
>> >>>
>> >>> -- Srinivas
>> >>>
>> >>>
>> >>> How common do
>> >>> you think that is? I take your idea seriously but would like to know
>> >>> when/why that happens.  Is it because of the Firefox bug where the
>> >>> hidden descendants are showing up in the name? (Because, if it's
>> >>> because of a bug I don't think we should add a new feature; we should
>> >>> just fix the bug instead).
>> >>>
>> >>> - Aaron
>> >>>
>> >>>
>> >>> Srinivas Annam wrote:
>> >>>> I would like to provide an additional example in the hopes of
>> > clarifying.
>> >>>> Take the scenario I would have used title which is also the case
>> >>>> where I don't have the text for acc name anywhere else. So by using
>> >>> aria-labelledby
>> >>>> for such case you would have to serve the additional bytes which
>> >>>> when multiplied by the number of times used in your application and
>> >>>> repeated
>> >>> over
>> >>>> millions of downloads it can make a huge difference in application
>> >>>> performance.
>> >>>>
>> >>>> Here I have code snippets for each case -
>> >>>>
>> >>>> *<div class="ofscr" id="stid">*My menu name*</div>* <div role="menu"
>> >>>> *aria-labelledby="stid"*>
>> >>>>     ... items go here
>> >>>> </div>
>> >>>>
>> >>>> vs.
>> >>>>
>> >>>> **<div role="menu" *aria-name="*My menu name*"*>
>> >>>>     ... items go here
>> >>>> </div>
>> >>>>
>> >>>>>  From above you can see that there is a difference of 48 bytes per
>> > usage,
>> >>> now
>> >>>> multiply that by three. Now, assume that you have 1M page servings /
>> > day,
>> >>>> you get 144MB of extra bytes to be served, all because I couldn't
>> >>>> use a title! :) Hope you get the idea.
>> >>>>
>> >>>> Thanks,
>> >>>> Srinivas
>> >>>> On Tue, Jul 22, 2008 at 9:10 AM, Srinivas Annam<annams@google.com
>> >>>> <mailto:annams@google.com> >
>> >>>   wrote:
>> >>>>> Jon,
>> >>>>>
>> >>>>> My point is aria-labelledby is a good work around but we should not
>> >>>>> *forced* to use it all the time. Additionally, I can not imagine
>> >>>>> names
>> >>> of
>> >>>>> menus and listboxes lying around in all of today's practical
>> >>> applications.
>> >>>>> I think we all agreed that because of the tooltip overload title
>> >>>>> has
>> >>> become
>> >>>>> unusable, given that I am proposing that we create an alternate and
>> >>>>> equivalent, such as aria-name in its place.
>> >>>>>
>> >>>>> Srinivas
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Jul 22, 2008 at 8:02 AM, Jon Gunderson<jongund@illinois.edu
>> >>>>> <mailto:jongund@illinois.edu>
>> >>>> wrote:
>> >>>>>> Srinivas,
>> >>>>>>
>> >>>>>> Personally I like aria-labelledby by since it is very flexible to
>> > reuse
>> >>>>>> content already on the page and could actually be configurable if
>> >>>>>> the
>> >>> web
>> >>>>>> application, if the developer provides an interface for the user
>> >>>>>> to configure what is included in the aria-labelledby list of
>> >>>>>> IDREFs.
>> >>>>>>
>> >>>>>> Example:
>> >>>>>>
>> >>>>>> http://test.cita.uiuc.edu/aria/grid/grid2.php
>> >>>>>> <http://test.cita.uiuc.edu/aria/grid/grid2.php>
>> >>>>>>
>> >>>>>> Jon
>> >>>>>>
>> >>>>>>
>> >>>>>> ---- Original message ----
>> >>>>>>> Date: Mon, 21 Jul 2008 16:14:02 -0700
>> >>>>>>> From: Srinivas Annam<annams@google.com <mailto:annams@google.com>
>> >>>>>>> >
>> >>>>>>> Subject: Re: Using title for ARIA name is impractical!
>> >>>>>>> To: Jon Gunderson<jongund@illinois.edu
>> >>>>>>> <mailto:jongund@illinois.edu> >
>> >>>>>>> Cc: dev-accessibility@lists.mozilla.org
>> >>>>>>> <mailto:dev-accessibility@lists.mozilla.org> , wai-xtech@w3.org
>> >>>>>>> <mailto:wai-xtech@w3.org>
>> >>>>>>>
>> >>>>>>>     Let me clarify this, my question is directly towards
>> >>>>>>>     roles that support title as a way of providing acc
>> >>>>>>>     name -- getting name from child content or
>> >>>>>>>     aria-labelledby are different use cases which are
>> >>>>>>>     not at discussion here. Given the side effect of
>> >>>>>>>     title to provide a tooltip for mouse hover can there
>> >>>>>>>     be or should there be an alternate mechanism? Why
>> >>>>>>>     not have aria-name which can provide the same
>> >>>>>>>     purpose but without the side effect?
>> >>>>>>>
>> >>>>>>>     -- Srinivas
>> >>>>>>>
>> >>>>>>>     On Mon, Jul 21, 2008 at 2:47 PM, Jon Gunderson
>> >>>>>>>     <jongund@illinois.edu <mailto:jongund@illinois.edu> >   wrote:
>> >>>>>>>
>> >>>>>>>       Srinivas,
>> >>>>>>>
>> >>>>>>>       The "option" role will use the DOM subtree text
>> >>>>>>>       nodes to generate an accessible name for each
>> >>>>>>>       option.
>> >>>>>>>       Jon
>> >>>>>>>
>> >>>>>>>       ---- Original message ----
>> >>>>>>>       >Date: Mon, 21 Jul 2008 13:02:41 -0700
>> >>>>>>>       >From: Srinivas Annam<annams@google.com
>> > <mailto:annams@google.com> >
>> >>>>>>>       >Subject: Using title for ARIA name is
>> >>>>>>>       impractical!
>> >>>>>>>       >To: dev-accessibility@lists.mozilla.org
>> > <mailto:dev-accessibility@lists.mozilla.org>
>> >>>>>>>       >Cc: wai-xtech@w3.org <mailto:wai-xtech@w3.org>
>> >>>>>>>       >
>> >>>>>>>       >In my continuing series of ARIA discoveries :)
>> >>>>>>>       >
>> >>>>>>>       >The current recommendation requires the usage of
>> >>>>>>>       title attribute to provide
>> >>>>>>>       >a name for widgets of the following roles:
>> >>>>>>>       combobox, grid, group, img, list,
>> >>>>>>>       >listbox, menu, menubar, progressbar, radiogroup,
>> >>>>>>>       slider, spinbutton,
>> >>>>>>>       >textbox, tree, treegrid.
>> >>>>>>>       >
>> >>>>>>>       >Now imagine a listbox or a tree with lot of
>> >>>>>>>       visible child elements and that
>> >>>>>>>       >each of these widgets (lisbox and options) are
>> >>>>>>>       being created using a div.
>> >>>>>>>       >The outerdiv for the listbox having it's role as
>> >>>>>>>       "listbox" and each of the
>> >>>>>>>       >list items having a role of "option". Now, assume
>> >>>>>>>       that the listbox has a
>> >>>>>>>       >title defined on it (so it could provide an acc
>> >>>>>>>       name per current
>> >>>>>>>       >recommendation) like below:
>> >>>>>>>       >
>> >>>>>>>       ><div role="listbox" title="My Own Listbox"
>> >>>>>>>       >aria-activedescendant="listbox1-1">
>> >>>>>>>       >    <div role="option" id="listbox1-1"
>> >>>>>>>       class="selected"
>> >>>>>>>       >aria-selected="true">item 1</div>
>> >>>>>>>       >    <div role="option" id="listbox1-2">item
>> >>>>>>>       2</div>
>> >>>>>>>       >    <div role="option" id="listbox1-3">item
>> >>>>>>>       3</div>
>> >>>>>>>       ></div>
>> >>>>>>>       >
>> >>>>>>>       >At this time you would notice that hovering over
>> >>>>>>>       with mouse on anywhere over
>> >>>>>>>       >the listbox area (including where the individual
>> >>>>>>>       items are shown) would show
>> >>>>>>>       >a tooltip with the title. This is coming in as a
>> >>>>>>>       side effect of browser
>> >>>>>>>       >usage of title for the tooltip. Given this major
>> >>>>>>>       UI implication, IMO, this
>> >>>>>>>       >makes the usage of title to get an acc name on
>> >>>>>>>       the roles mentioned highly
>> >>>>>>>       >impractical. I would like to hear other thoughts
>> >>>>>>>       or ideas. Or if someone
>> >>>>>>>       >knows a way of getting ARIA name without using a
>> >>>>>>>       title.
>> >>>>>>>       >
>> >>>>>>>       >Thanks,
>> >>>>>>>       >Srinivas
>> >>>>>>>       >
>> >>>>>>>       >--
>> >>>>>>>       >Srinivas Annam
>> >>>>>>>       >Software Engineer, Accessibility
>> >>>>>>>       >Google, Inc.
>> >>>>>>>       >Cell: 408.898.4928
>> >>>>>>>       >Email: annams@google.com <mailto:annams@google.com>
>> >>>>>>>       >_______________________________________________
>> >>>>>>>       >dev-accessibility mailing list
>> >>>>>>>       >dev-accessibility@lists.mozilla.org
>> > <mailto:dev-accessibility@lists.mozilla.org>
>> >>>>>>>       >https://lists.mozilla.org/listinfo/dev-accessibility
>> > <https://lists.mozilla.org/listinfo/dev-accessibility>
>> >>>>>>>       Jon Gunderson, Ph.D.
>> >>>>>>>       Coordinator Information Technology Accessibility
>> >>>>>>>       Disability Resources and Educational Services
>> >>>>>>>
>> >>>>>>>       Rehabilitation Education Center
>> >>>>>>>       Room 86
>> >>>>>>>       1207 S. Oak Street
>> >>>>>>>       Champaign, Illinois 61821
>> >>>>>>>
>> >>>>>>>       Voice: (217) 244-5870
>> >>>>>>>
>> >>>>>>>       WWW: http://www.cita.uiuc.edu/ <http://www.cita.uiuc.edu/>
>> >>>>>>>       WWW: https://netfiles.uiuc.edu/jongund/www/
>> >>>>>>> <https://netfiles.uiuc.edu/jongund/www/>
>> >>>>>>>
>> >>>>>>>     --
>> >>>>>>>     Srinivas Annam
>> >>>>>>>     Software Engineer, Accessibility
>> >>>>>>>     Google, Inc.
>> >>>>>>>     Cell: 408.898.4928
>> >>>>>>>     Email: annams@google.com <mailto:annams@google.com>
>> >>>>>> Jon Gunderson, Ph.D.
>> >>>>>> Coordinator Information Technology Accessibility Disability
>> >>>>>> Resources and Educational Services
>> >>>>>>
>> >>>>>> Rehabilitation Education Center
>> >>>>>> Room 86
>> >>>>>> 1207 S. Oak Street
>> >>>>>> Champaign, Illinois 61821
>> >>>>>>
>> >>>>>> Voice: (217) 244-5870
>> >>>>>>
>> >>>>>> WWW: http://www.cita.uiuc.edu/ <http://www.cita.uiuc.edu/>
>> >>>>>> WWW: https://netfiles.uiuc.edu/jongund/www/
>> >>>>>> <https://netfiles.uiuc.edu/jongund/www/>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>> --
>> >>>>> Srinivas Annam
>> >>>>> Software Engineer, Accessibility
>> >>>>> Google, Inc.
>> >>>>> Cell: 408.898.4928
>> >>>>> Email: annams@google.com <mailto:annams@google.com>
>> >>>>>
>> >>>>
>> >>>>
>> >>> _______________________________________________
>> >>> dev-accessibility mailing list
>> >>> dev-accessibility@lists.mozilla.org
>> >>> <mailto:dev-accessibility@lists.mozilla.org>
>> >>> https://lists.mozilla.org/listinfo/dev-accessibility
>> >>> <https://lists.mozilla.org/listinfo/dev-accessibility>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Srinivas Annam
>> >>> Software Engineer, Accessibility
>> >>> Google, Inc.
>> >>> Cell: 408.898.4928
>> >>> Email: annams@google.com <mailto:annams@google.com>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Srinivas Annam
>> > Software Engineer, Accessibility
>> > Google, Inc.
>> > Cell: 408.898.4928
>> > Email: annams@google.com <mailto:annams@google.com>
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
> --
> Srinivas Annam
> Software Engineer, Accessibility
> Google, Inc.
> Cell: 408.898.4928
> Email: annams@google.com
>

Received on Friday, 1 August 2008 09:43:42 UTC