Open Bug 340809 (textattra11y) Opened 14 years ago Updated 7 months ago

[meta] Text formatting not exposed to screen readers, inaccessible

Categories

(Core :: Disability Access APIs, defect)

defect
Not set

Tracking

()

People

(Reporter: aaronlev, Unassigned)

References

(Depends on 5 open bugs, Blocks 2 open bugs)

Details

(Keywords: access, meta, Whiteboard: orca:normal)

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)
css.property=value
dom.attributename=value or dom.namespaceabbrev.attributename=value (if namespace different from tag)
headlinglevel=#

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 :(
Correct, for tag names, let's always include the namespace abbrev ad always use the "." instead of the ":"
so always
tag=nasmespaceabbrev.tagname
Also, CSS attributes should only be exposed if different from parent. Will also be used for text run attributes.
This can be done in nsAccessibleWrap.
The ATKText attributes come via GetAttributeRange(). We just need to turn the CSS for the given accessible into an AttributeSet.
Summary: New ATK: Implement AtkObject attributes → New ATK: Implement AtkObject and AtkText attributes
Assignee: nobody → gaomingcn
Also expose heading level=n
and for static text, static=true
Marking dependent on the simpler bug to just expose tag name and heading level.
Depends on: 342288
Summary: New ATK: Implement AtkObject and AtkText attributes → New ATK: Implement all AtkObject and AtkText attributes
Whiteboard: Need more specifics on what to expose or not expose
Depends on: 340670
Depends on: 345723
Depends on: 345759
Depends on: 287737
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.
We need to finalize a plan before continuing. Here's a wiki page for that:
http://wiki.mozilla.org/Accessibility/Attributes#Proposed_AT-SPI_Attribute_Support
Assignee: gaomingcn → aaronleventhal
Blocks: texta11y
No longer blocks: newatk
(In reply to comment #8)
> We need to finalize a plan before continuing. Here's a wiki page for that:
> http://wiki.mozilla.org/Accessibility/Attributes#Proposed_AT-SPI_Attribute_Support
> 
Hi Aaron.  What's the status of this?  We've had a user ask about access to attribute information.

Thanks!!
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.
Blocks: orca
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 http://wiki.mozilla.org/Accessibility/Attributes
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 http://developer.mozilla.org/en/docs/Accessibility/ATSPI_Support
Assignee: aaronleventhal → ginn.chen
Summary: New ATK: Implement all AtkObject and AtkText attributes → New ATK: Implement all text attributes for ATK and IA2
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?
(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).  
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.

http://www.linux-foundation.org/en/Accessibility/IAccessible2/TextAttributes
Note that CAccessibleText::get_attributes() (which is for text attributes) incorrectly calls IAccessible2:get_attributes() (which is for object attributes)
Whiteboard: Need more specifics on what to expose or not expose → orca:normal
Assignee: ginn.chen → surkov.alexander
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.
Keywords: sec508
Summary: New ATK: Implement all text attributes for ATK and IA2 → Text formatting not exposed to screen readers, inaccessible
Blocks: fox3access
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?
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.
Let see an example

      color:red
 |               |
some text some text
      |       |
   bgcolor:green

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?
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?
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.


Assignee: surkov.alexander → aaronleventhal
Component: Disability Access → Disability Access APIs
OS: Linux → All
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Hardware: PC → All
Ok, let start from support of misspelling attribute, what's about startOffset and endOffset, should I care?
Depends on: 408793
Depends on: 445509
Depends on: 445510
Depends on: 445511
Depends on: 445513
Depends on: 445516
Depends on: 445677
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. :-)
(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.
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!
Depends on: 445938
Depends on: 445968
Assignee: aaronleventhal → nobody
Summary: Text formatting not exposed to screen readers, inaccessible → [meta] Text formatting not exposed to screen readers, inaccessible
Depends on: 451376
Depends on: 453605
No longer depends on: 453605
Depends on: 454805
Depends on: 455834
Depends on: 460932
Depends on: 462868
Depends on: 467146
Depends on: 473569
Depends on: 473570
Depends on: 473573
Depends on: 473576
Depends on: 407592
Depends on: 453605
Depends on: 475522
Depends on: 481389
Depends on: 523304
Depends on: 408185
Alias: textattra11y
Depends on: 732366
Depends on: 735645
Depends on: 789621
Depends on: 829354
You need to log in before you can comment on or make changes to this bug.