Open Bug 340809 (textattra11y) Opened 16 years ago Updated 3 years ago
[meta] Text formatting not exposed to screen readers, inaccessible
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
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
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
(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.
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
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.
Summary: New ATK: Implement all text attributes for ATK and IA2 → Text formatting not exposed to screen readers, inaccessible
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?
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!
Assignee: aaronleventhal → nobody
Summary: Text formatting not exposed to screen readers, inaccessible → [meta] Text formatting not exposed to screen readers, inaccessible
You need to log in before you can comment on or make changes to this bug.