Hi, Pete. I'm not Jamie but hope my answer makes sense :)
I think AT might want to announce that explicit name (say on focus) and then use IAText to expose styles and subtree markup depending on user interaction. Personally I would avoid artificial accessible objects since they complicates implementation. Thank you. Alex. On Tue, Jul 26, 2011 at 1:06 AM, Pete Brunet <[email protected]> wrote: > 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 > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
