Thanks Jamie, If both the accName and IAText::text are not helpful in this case then it appears that we need IA2_2::explicitName rather than a boolean property like IA2_2::isNameExplicit. I assume the flag was to indicate that the accName was derived from ancillary content such as HTML attributes or associated labels.
See also: https://lists.linux-foundation.org/pipermail/accessibility-ia2/2011-June/001339.html However, how would you get the text attributes in the case of using IA2_2::explicitName? That string will be different from IAText::text. It seems like you'd need the browser to create a new object containing the newly formed string from main content plus the HTML attributes and/or the associated label. In that case we'd instead need IA2_2::explicitAccessible returning an object which you could then QI to get the generated text and associated text attributes. Pete On 7/23/2011 1:35 AM, James Teh wrote: > On 23/07/2011 2:43 AM, Pete Brunet wrote: >> Why doesn't NVDA just always use accName for normal browsing instead of >> IAText::text? If that were the case then there would be no need to know >> when accName is different than IAText::text. > In NVDA browse mode (also known as virtual cursor, virtual buffer, etc. > in other screen readers), the text is presented to the user in a flat > representation to make it readable as if the user were working with, > say, a word processor. Thus, we want to keep the content as close as > possible to the original content. Some reasons we don't always use > accName to retrieve this content (and this is by no means an exhaustive > list): > 1. accName might contain content from descendant objects; e.g. a table > row, a link containing a graphic, etc. If we just use accName, we must > choose to either ignore information from all descendant objects (thus > losing semantic information) or render content from those descendant > objects and try to filter out duplicates (very ugly and complicated). > 2. In the case of editable text fields and some other form controls, the > name is not what we want. Instead, we want the value or text. (If the > label is visible on screen, we do render it, but that's because we take > the content from the label object.) > 3. accName contains no text attributes, so all information about > formatting would be lost. (NVDA doesn't currently report this > information for Firefox, but we plan to rectify this soon.) > Of course, we still want to honour overrides like aria-label, etc., > hence the request under discussion. > > Btw, I'm confused by your use of the term explicit name. I would have > thought explicit name was the name the author "explicitly" requested > (i.e. the override) rather than the original, non-overridden name. This > is why I used terms like "override" and "from content" in my original > proposal. We probably need to straighten out this terminology. Perhaps > I'm the only one who is confused by this? :) > > Jamie > -- *Pete Brunet* a11ysoft - Accessibility Architecture and Development (512) 467-4706 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), [email protected] (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
