Reassigned to ES.

Reassigned to OBR

@od: what is the OOo term for this ? Paragraph template ?

Whether a piece of text is a heading or not should probably get exposed via the role of that object, even 
though this might not implemented in writer yet due to a lack of an "accessible role changed" event.

Even though I think the template name is not a classical text attribute, I agree it might make sense to 
expose it as such. But we probably want a localized name, right ? 

The OOo term is: Paragraph Style

Yes, you are right, that the Paragraph Style of a paragraph isn't an attribute
of the paragraph. It is possible to provide the name of the Paragraph Style of a
paragraph at our accessibility API. But, keep in mind, that in OOo a Paragraph
Style can have a parent Paragraph Style. Thus, the Paragraph Styles can build a
hierarchy.
What do you mean by "localized name"? The name of the Paragraph Style, which is
shown in the Styles and Formatting dialog?

I meant: if I write a document with a german OOo using the style "Ãœberschrift 1", will this automatically 
become "Heading 1" when I read the document in an en-US version of OOo ?

Ok, that's what I have assumed.
Internally, we distinguish between programmatic names and display names for
Styles. These names can also be found in the OpenDocument file format.

I wasn't sure how significantly voting is taken into consideration here, so I'm
voting AND commenting. :-)

I realize that you all are quite busy, but if exposing this -- and similar --
information via at-spi could somehow be prioritized, that would be awesome.  

As it currently stands, there is still quite a bit of formatting which a sighted
user can obtain immediately with a mere glance that a blind user cannot.  (In
addition to this bug, please see issues #71385, #72161, #70872)  In order for a
blind user to obtain this information, he/she must move to the relevant
toolbar/dialog box controls and examine their values. The problem with this
method is two-fold:

1. The user has to suspect that there is something worth checking for.

2. For each character or paragraph (depending on the attribute in question) to
be checked, the user has to take the time to move to the text in question, then
navigate to the toolbar/dialog in question, then navigate to the control in
question, and finally return to the document to repeat the entire process for
the next bit of text.

Given a sufficiently lengthy document, item #2 could take a blind user an hour
whereas the equivalent check could be done by other (sighted) users in mere
minutes. 

As for item #1:  In my experience, most users tend to suspect that they have
correctly applied the formatting they intended --  not that they've managed to
significantly mess up their document with unintended attributes. :-)  As a
result, the typical user is likely to “double-check†the formatting he/she
expects to be present and relatively unlikely to check the remainder of the
document for unintended formatting (because doing so currently takes so much
time!).  The end result, unfortunately, is not always what the user thinks it is.

Were all of this information to be exposed via at-spi, Orca (and other screen
readers) could be scripted to present the user with, say, all of the non-default
formatting.  That would enable users who are blind to use OOo MUCH more
effectively, efficiently, and with confidence that their documents look as they
intend.

Thank you VERY much for your time and consideration!!

Adding most of the missing text attribute mappings is on my to-do list for early next year. What makes 
setting a specific target milestone difficuilt is that some of the issues request one or two items to be 
exposed as text attributes which are no text attributes in the OOo core (like the style one here).

@mt,od: do we all agree with exposing the display name of the paragraph style as text attibute ?

Sure, style name is important information.

It's something like a paragraph attribute, so it can be returned in default
attributes.

Sure, style name is important information.

It's something like a paragraph attribute, so it can be returned in default
attributes.

Joanie has done a nice job of outlining the problems posed by the fact that 
this sort of information isn't exposed.  As a real world example of why this is 
important, take my situation.  I am visually impaired myself, and a 
professional in the industry of assistive technology.  Recently, I  had cause 
to update my resume.  I would have preferred to do so using OOo under Linux; 
However, due to the issues described above, I was forced to rely on Ms Word.  

Until OOo is able to provide this sort of information to a  screen reader, it 
will be impractical for those of us who rely on this technology to use it for 
anything other than the editing of very basic documents.

I have file issue 72800 to track the implementation in the word processor module
(writer).

Created attachment 41649 [details]
This patch adds font name mapping to OOo

Do patches such as this one get included in the next developer snapshot?

No, not automatically. Before some code change can be integrated into the main code line, it needs to get 
tested on a dedicated CVS branch (we call this a Child Workspace (CWS)). My plan is to open such a CWS 
early next year.

Just applied the patch adding font name support in CWS atkbridge5.

MD->OBR: As discussed, please put it into the 2.2 release.

gsl/vcl/unx/gtk/a11y/atktextattributes.cxx revision 1.4.136.3 now exposes the
style name as "paragraph-style" attribute.

please verify.

Verified in atkbridge5

Ok in OOF_m5