Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 340809 - (textattra11y) [meta] Text formatting not exposed to screen readers, inaccessible
: [meta] Text formatting not exposed to screen readers, inaccessible
Status: NEW
: access, sec508
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: alexander :surkov
Depends on: 445511 453605 454805 481389 732366 829354 287737 340670 342288 345723 345759 407592 408185 408793 445509 445510 445513 445516 445677 445938 445968 451376 455834 460932 462868 467146 473569 473570 473573 473576 475522 523304 735645 789621
Blocks: texta11y orca fox3access
  Show dependency treegraph
Reported: 2006-06-08 04:29 PDT by Aaron Leventhal
Modified: 2013-01-10 16:53 PST (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Aaron Leventhal 2006-06-08 04:29:42 PDT
ATK now allows us to expose meaningful semantics via object attributes.
The object attribute must never have a colon in it, we should use a "." instead.

We should expose:
tag=[tagname] or tag=namespaceabbrev:value (if namespace different from parent)
dom.attributename=value or dom.namespaceabbrev.attributename=value (if namespace different from tag)

namespaceabbrev can be:
"html", "svg", "xul", "mathml", "xhtml2", "aaa", or "xforms"
otherwise we will have to expose the namespace URI for that, without any colons in it :(
Comment 1 Aaron Leventhal 2006-06-08 04:32:05 PDT
Correct, for tag names, let's always include the namespace abbrev ad always use the "." instead of the ":"
so always
Comment 2 Aaron Leventhal 2006-06-08 04:35:16 PDT
Also, CSS attributes should only be exposed if different from parent. Will also be used for text run attributes.
Comment 3 Aaron Leventhal 2006-06-14 04:41:30 PDT
This can be done in nsAccessibleWrap.
Comment 4 Aaron Leventhal 2006-06-19 07:33:33 PDT
The ATKText attributes come via GetAttributeRange(). We just need to turn the CSS for the given accessible into an AttributeSet.
Comment 5 Aaron Leventhal 2006-06-21 08:50:06 PDT
Also expose heading level=n
and for static text, static=true
Comment 6 Aaron Leventhal 2006-06-21 08:50:59 PDT
Marking dependent on the simpler bug to just expose tag name and heading level.
Comment 7 Aaron Leventhal 2006-09-13 11:48:19 PDT
Actually I no longer want to expose all DOM attributes and all CSS properties, just targeted ones.

Will file a separate bug for dealing with text formatting.
Comment 8 Aaron Leventhal 2006-10-05 12:33:35 PDT
We need to finalize a plan before continuing. Here's a wiki page for that:
Comment 9 Joanmarie Diggs 2007-04-27 19:21:23 PDT
(In reply to comment #8)
> We need to finalize a plan before continuing. Here's a wiki page for that:
Hi Aaron.  What's the status of this?  We've had a user ask about access to attribute information.

Comment 10 Aaron Leventhal 2007-04-29 19:24:10 PDT
I'd like to have this implemented by mid-June for sure. We want to stabilize what we have first, and fix some other really bad bugs, before taking on something new.
Comment 11 Aaron Leventhal 2007-06-21 02:39:30 PDT
1. We are basically done with object and document attributes, so this bug is just for text attributes now
2. We need to support what is at
3. I don't see something listed for subscript/superscript -- need to investigate what Open Office does for that.
4. Please look over what it says for default attributes column -- I wasn't sure if all text attributes can also be a default attribute, and vice versa
5. Don't forget to update
Comment 12 Aaron Leventhal 2007-06-21 02:54:40 PDT
More questions regarding default text attributes:
* How/why are they useful?
* They're not in IA2 -- what functionality will IA2 clients miss since it's not there? Or is there another way to emulate default text attributes
* What does Open Office use default text attributes for?
Comment 13 Joanmarie Diggs 2007-06-21 08:32:23 PDT
(In reply to comment #12)

I think there are two reasons/cases for caring about text attributes:

1. You want/need to know exactly how a given bit of text is formatted because you care about its appearance. (duh! :-) )

2. You want to quickly scan over a document to get an overview of its structure and/or locate important sections -- and one way to do that is to find the text whose formatting does not match the surrounding text. For example if the text in the entire document is bold, italic, and pink, those attributes are not interesting/meaningful/significant.  On the other hand, if the entire document has more conventional formatting, the appearance of the aforementioned attributes is indeed interesting/meaningful/significant.

> * How/why are they useful?
> * They're not in IA2 -- what functionality will IA2 clients miss 
> since it's not there? 

The ability to address case 2 efficiently.  If the "special" formatting is all that is exposed for the character's attributes, an AT could quickly query that.  (For case 1, the AT would need to combine the default attributes with the current character's attributes.)

If *all* attributes (i.e. even the "inherited" ones) that apply to a given character are exposed as that character's attributes, AT has quite a bit more work to do for case 2:  In order to identify if the current character is "special", the AT would have to compare all of its attributes with all of the attributes from something else, be it another character or a pre-defined set of attributes.

> * What does Open Office use default text attributes for?
I'm *pretty* sure that there the default attributes are those that apply to all of the text in the current paragraph, which to me is not ideal.  Often "special" formatting applies to an entire paragraph (such as documents in which a section is delineated by a single-line paragraph which is bold and in larger font).  
Comment 14 Aaron Leventhal 2007-06-25 13:33:40 PDT
Ginn, Pete Brunet is working on a doc for IA2 to try and standardize text attributes between various applications. Of course we want to have the same text attributes between ATK and Mozilla.

You can take a look -- Pete is planning to add recommendations for restrictions on units and format, etc.
Comment 15 Aaron Leventhal 2007-08-09 18:49:09 PDT
Note that CAccessibleText::get_attributes() (which is for text attributes) incorrectly calls IAccessible2:get_attributes() (which is for object attributes)
Comment 16 Aaron Leventhal 2007-11-15 11:34:44 PST
Surkov, want to work on this? Work with Marco and Ginn and have it tested a lot. It's pretty crucial for web app and Thunderbird a11y.

I think we're in good enough shape on the other stuff to look at this.
Comment 17 alexander :surkov 2007-11-17 09:39:48 PST
I do not get about out arguments startOffset and endOffset of a range we returns attributes for. Are they minimal offsets amoung of all offsets for each attribute? If so then I think it should be hard enough to calculate them and I'm not sure if it's needed at all. It's probably better to return all attributes for the given point but to provide new method to get offsets for specified attribute. What do you think?
Comment 18 Aaron Leventhal 2007-11-17 11:50:06 PST
Surkov, for some reason I'm not understanding what you mean. Are you talking about just changing nsIAccessibleText?

Whatever makes sense in terms of implementing the right thing to AtkText and IAccessibleText.

One thing we're still deciding is whether for each accessible text, to expose all the text attributes it has or just the ones that have changed. I'm currently discussing this with AT vendors.

So, as you look at this right now be prepared that the decision could still go either way.
Comment 19 alexander :surkov 2007-11-17 19:14:30 PST
Let see an example

 |               |
some text some text
      |       |

IA2 propose:

[propget] HRESULT attributes
     [in] long offset,	
     [out] long *startOffset,
     [out] long *endOffset,	
     [out, retval] BSTR *textAttributes

What should start and end offsets be if I expose two attributes color and background-color?

If we would expose only last changed attribute then do we have an event for this?
Comment 20 alexander :surkov 2007-11-17 19:25:57 PST
btw, is "misspelling" attribute from bug 345759 is going to be official text attribute?

We won't support text attributes from ODF, isn't there an analgue used in gecko?

If we will expose only last changed attribute then do we have a way to watch what was changed, for example, if style rule has been applied then do we able to get notification for each rule item separetely?
Comment 21 Aaron Leventhal 2007-11-18 07:51:11 PST
Surkov: about change events -- we should think of what the use cases are for that. For Firefox 3, I think it would be good enough if text attribute change events were only fired for misspellings. That is the most likely text attribute to change where the user wasn't expecting it already. It would be good to get other's thoughts on that.

AFAIK, ODF does not expose a semantic attribute for misspellings. They might indicate that there is a red underline, but that is not really useful. I suggest we simply go with something like misspelling=true. It is the most useful for screen readers.

Comment 22 alexander :surkov 2007-11-18 08:04:06 PST
Ok, let start from support of misspelling attribute, what's about startOffset and endOffset, should I care?
Comment 23 Joanmarie Diggs 2008-07-17 17:40:00 PDT
Silly question: I'm catching up on my bugzilla mail and was notified of this new bug "[Bug 445513] New: Support BOUNDARY_ATTRIBUTE_RANGE now that we support text attributes"

Text attributes are supported now? Is this for ATK as well?  If so, I'm not seeing them (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre) Gecko/2008071622 Minefield/3.1a1pre). If not, never mind. :-)
Comment 24 alexander :surkov 2008-07-17 19:04:40 PDT
(In reply to comment #23)

> Text attributes are supported now? Is this for ATK as well?  If so, I'm not
> seeing them (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre)
> Gecko/2008071622 Minefield/3.1a1pre). If not, never mind. :-)

Yes, yesterday we have introduced the support of text attributes. They should work in ATK as well. Please try today build.
Comment 25 Joanmarie Diggs 2008-07-17 19:58:37 PDT
By george, you're right!  Attributes! Yea!! ;-)

Sorry about that. I suppose I should have built first and then asked.  But I figured building FF each and every night, relatively late at night, would have me sufficiently current. Now I know better. :-)

Thanks Alexander!

Note You need to log in before you can comment on or make changes to this bug.