Hi, Pete. I don't clearly understand what you could mean by adaptation. But it sounds "from context" meaning "from accessible subtree including text" is what Firefox does.
Alex. On Mon, Jul 25, 2011 at 11:38 PM, Pete Brunet <[email protected]> wrote: > I like the terms "override" and "from context". I think Alex is saying > explicit and override are the same, but it sounds like "implicit" == > "browser tries to fix name" might be something different than "from > context". > > Alex, Are you saying that "implicit" indicates a third means of > presenting content taken from the original content but adapted by the > browser but not overridden by content attributes or content outside the > node such as from a label? > > Pete > > On 7/23/2011 4:00 AM, Alexander Surkov wrote: >>> 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? :) >> explicit in means author specified it (for example, label element is >> used or ARIA), implicit is otherwise, i.e. when browser tries to fix >> name. Though I can see your point if you meant ARIA usage as a way to >> override name. >> >> Alex. >> >> On Sat, Jul 23, 2011 at 3:35 PM, James Teh <[email protected]> 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 >>> >>> -- >>> James Teh >>> Vice President, Developer >>> NV Access Inc, ABN 61773362390 >>> Email: [email protected] >>> Web site: http://www.nvaccess.org/ >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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
