Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IAccessible2 "level" object attribute not taken into account for heading levels #15881

Closed
michaelweghorn opened this issue Dec 5, 2023 · 1 comment · Fixed by #15882
Closed

IAccessible2 "level" object attribute not taken into account for heading levels #15881

michaelweghorn opened this issue Dec 5, 2023 · 1 comment · Fixed by #15882
Milestone
2024.1

Comments

@michaelweghorn
Copy link
Contributor

The "level" object attribute for IAccessible2 to specify the level of a heading is both mentioned in the Core Accessibility API Mappings specification and in the IAccessible2::groupPosition documentation.

Quoting from the latter (emphasis added):

This method is meant to describe the nature of an object's containment
structure. It's exposed by trees, tree grids, nested lists, nested
menus, but not headings, which uses the level object attribute.

However, apparently NVDA does not actually support/evaluate this object attribute in order to determine the heading level, as I noticed while working on making LibreOffice adhere more closely to platform APIs/specifications.

Steps to reproduce:

  1. start NVDA
  2. start current development version of LibreOffice including the following change that drops reporting the non-standard "heading-level" object attribute: https://gerrit.libreoffice.org/c/core/+/160347
  3. open the attached sample document heading.odt
  4. use the cursor up/down key to move between the paragraphs/headings

Actual behavior:

When the focus moves to a heading, the heading level is not spoken. NVDA e.g. just says "heading Heading 1".

Expected behavior:

The heading level (as reported by the "level" object attribute") should be announced by NVDA, as was the case without the above-mentioned LibreOffice change in place e.g. "heading level 1 Heading 1"

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

running from source

NVDA version:

git master as of commit 9cf9251

Windows version:

Windows 10

Name and version of other software in use when reproducing the issue:

LibreOffice git master (24.2 alpha) as of commit 29fc0ec9930fc1c09c0e79d41c56f93ae853c054 + these 2 pending changes on top:
https://gerrit.libreoffice.org/c/core/+/160346/1
https://gerrit.libreoffice.org/c/core/+/160347/1

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

n/a

Have you tried any other versions of NVDA? If so, please report their behaviors.

If NVDA add-ons are disabled, is your problem still occurring?

n/a

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

n/a
@michaelweghorn
Copy link
Contributor Author

I plan to submit a PR with a suggested fix.

michaelweghorn added a commit to michaelweghorn/nvda that referenced this issue Dec 5, 2023
@michaelweghorn
IA2: Evaluate "level" object attribute
4cb2833 
 ### Link to issue number:

Fixes nvaccess#15881

 ### Summary of the issue:

The "level" object attribute for IAccessible2 to specify the level of a heading is both mentioned in the [Core Accessibility API Mappings specification](https://www.w3.org/TR/core-aam-1.2/#ariaLevelHeading) and in the [IAccessible2::groupPosition documentation](https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible2.html#a94d4d84e000ef2fa3f2abf1148779941).
However, NVDA was not supporting/evaluating this object attribute in
order to determine the heading level, resulting in the heading level no
longer getting announced once LibreOffice only reports the "level"
attribute as specified and no longer the custom "heading-level"
attribute that NVDA's soffice app module relies on.

 ### Description of user facing changes

Reporting heading levels also works for LibreOffice version 24.2 and
greater.

 ### Description of development approach

Add handling for the "level" IAccessible2 object attribute when
determining position info for an IAccessible2 object.
In the soffice app module, add a comment that the custom "heading-level"
attribute is only needed for Apache OpenOffice by now, since
LibreOffice has already been reporting the "level" object attribute
in addition to the "heading-level" attribute since LibreOffice 5.0.

 ### Testing strategy:

Test the scenario as described in issue nvaccess#15881 works as expected with
this change in place:

1. start NVDA
2. start current development version of LibreOffice including the following change that drops reporting the non-standard "heading-level" object attribute: https://gerrit.libreoffice.org/c/core/+/160347
3. open the sample document [heading.odt](https://github.com/nvaccess/nvda/files/13560391/heading.odt)
4. use the cursor up/down key to move between the paragraphs/headings
5. When moving to a header, verify that NVDA announces the heading level, e.g. says "heading    level 1  Heading 1".

 ### Known issues with pull request:

none

 ### Code Review Checklist:

- [x] Documentation:
  - Change log entry
  - User Documentation
  - Developer / Technical Documentation
  - Context sensitive help for GUI changes
- [x] Testing:
  - Unit tests
  - System (end to end) tests
  - Manual testing
- [x] UX of all users considered:
  - Speech
  - Braille
  - Low Vision
  - Different web browsers
  - Localization in other languages / culture than English
- [x] API is compatible with existing add-ons.
- [x] Security precautions taken.
This was referenced Dec 5, 2023
Merged
Open
seanbudd pushed a commit that referenced this issue Dec 6, 2023
@michaelweghorn
IA2: Evaluate "level" object attribute (#15882)
04120db 
Fixes #15881

Summary of the issue:
The "level" object attribute for IAccessible2 to specify the level of a heading is both mentioned in the Core Accessibility API Mappings specification and in the IAccessible2::groupPosition documentation. However, NVDA was not supporting/evaluating this object attribute in order to determine the heading level, resulting in the heading level no longer getting announced once LibreOffice only reports the "level" attribute as specified and no longer the custom "heading-level" attribute that NVDA's soffice app module relies on.

Description of user facing changes
Reporting heading levels also works for LibreOffice version 24.2 and greater.

Description of development approach
Add handling for the "level" IAccessible2 object attribute when determining position info for an IAccessible2 object. In the soffice app module, add a comment that the custom "heading-level" attribute is only needed for Apache OpenOffice by now, since LibreOffice has already been reporting the "level" object attribute in addition to the "heading-level" attribute since LibreOffice 5.0.
@nvaccessAuto nvaccessAuto added this to the 2024.1 milestone Dec 6, 2023
tdf-gerrit pushed a commit to LibreOffice/core that referenced this issue Dec 7, 2023
@michaelweghorn
sw a11y: Only report "level", no more "heading-level" obj attr
185cd83 
Stop reporting the custom "heading-level" object attribute in
addition to the "level" attribute.
As described in the Core Accessibility API Mappings spec, the
latter is specified in ARIA and maps to an attribute of
the same name for all of AT-SPI2, IAccessible2 and UIA [1].

Get rid of the non-documented "heading-level" as part of the
goal to align more closely to platform APIs/specifications.

NVDA's LibreOffice-specific app module currently relies on the
custom "heading-level" object attribute [2], but I've reported
an issue and submitted a pull request for this: [3] [4]

While neither the "level" nor the "heading-level" attribute are
currently mentioned in the the IAccessible2 object attribute
specification [5], the IAccessible2 doc for
`IAccessible2::groupPosition` [6] explicitly mentions
the "level" attribute for headings:

> This method is meant to describe the nature of an object's containment
> structure. It's exposed by trees, tree grids, nested lists, nested
> menus, but not headings, which uses the level object attribute.

[1] https://www.w3.org/TR/core-aam-1.2/#ariaLevelHeading
[2] https://github.com/nvaccess/nvda/blob/9cf925195e0fc5ffc67dcfcc9e4d4a7d46ffb430/source/appModules/soffice.py#L225
[3] nvaccess/nvda#15881
[4] nvaccess/nvda#15882
[5] https://wiki.linuxfoundation.org/accessibility/iaccessible2/objectattributes
[6] https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible2.html#a94d4d84e000ef2fa3f2abf1148779941

Change-Id: I8e8994cc7565f9b0f40ca8bedff951512f56b59b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160347
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
michaelweghorn added a commit to michaelweghorn/nvda that referenced this issue Apr 17, 2024
@michaelweghorn
soffice: Report keyboard-triggered formatting toggles in Writer
87251f5 
 ### Link to issue number:

Fixes nvaccess#15881

 ### Summary of the issue:

When toggling text formatting in LibreOffice Writer using
keyboard shortcuts (eg. Ctrl+B for toggling bold when using
English UI), NVDA was not reporting whether bold was enabled
or not.

 ### Description of user facing changes

In LibreOffice Writer (version 24.8 and newer), when toggling text
formatting (bold, italic, underline, subscript/superscript, alignment)
using the corresponding keyboard shortcut, NVDA announces
the new formatting attribute (e.g. "Bold on", "Bold off"),
similar to how it does for Microsoft Word.

 ### Description of development approach

In the SymphonyDocument class,
register gestures for keyboard shortcuts that
can be used to toggle formatting in LibreOffice Writer.

Add a method to handle the gestures, which is the same
for all attributes and enables processing of state
change events on toolbar buttons until a timeout
(of currently 0.15 seconds) is reached.
During that time, when a state change event for
a toolbar button is received from LibreOffice,
the name of the button and its new state (on/off)
are announced.

This also requires a corresponding change in LibreOffice [1]
so that the state change events for toolbar buttons
are actually sent, contained in LibreOffice >= 24.8:

    commit 0425b6eb47830b1fe630dc0128d5049f4b3e5582
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Tue Apr 16 19:02:30 2024 +0200

        tdf#160695 wina11y: Send status change events for toolbar buttons

Note: An alternative approach querying the text attributes
from the IAccessibleText interface instead of the button
state would run into the problem that it works reliably when
text is selected, but has no clear way to figure out whether
or not bold is enabled or not when there's no selection.
(The text attributes need to be queried for a given index, but
when the text cursor is e.g. in front of the first character of
non-bold text, Ctrl+B would enable bold for newly typed text, but
querying the text attributes at index 0 of the existing text
would still not report bold, resulting in issues like
as observed and described in issue nvaccess#16412 for MS Word.)

[1] https://git.libreoffice.org/core/commit/0425b6eb47830b1fe630dc0128d5049f4b3e5582

 ### Testing strategy:

1. start NVDA
2. start LibreOffice Writer (current development version, e.g. an
   upcoming daily build available from [2]).
3. Press Ctrl+B to enable Bold
4. Verify that NVDA announces "Bold on"
5. Press Ctrl+B again to disable bold formatting
6. Verify that NVDA announces "Bold off"
7. Type "hello world"
8. repeat steps 3-6
9. move text cursor to the beginning of the text
10. repeat steps 3-6
11. select the text
12. repeat steps 3-6
13. repeat steps 1-12 for other formatting attributes
    (Ctrl+I for italic, Ctrl+U for underline,...)

[2] https://dev-builds.libreoffice.org/daily/master/current.html

 ### Known issues with pull request:

None

 ### Code Review Checklist:

- [x] Documentation:
  - Change log entry
  - User Documentation
  - Developer / Technical Documentation
  - Context sensitive help for GUI changes
- [x] Testing:
  - Unit tests
  - System (end to end) tests
  - Manual testing
- [x] UX of all users considered:
  - Speech
  - Braille
  - Low Vision
  - Different web browsers
  - Localization in other languages / culture than English
- [x] API is compatible with existing add-ons.
- [x] Security precautions taken.
@michaelweghorn michaelweghorn mentioned this issue Apr 17, 2024
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
2024.1
Development

Successfully merging a pull request may close this issue.

IA2: Evaluate "level" object attribute michaelweghorn/nvda
2 participants
@michaelweghorn @nvaccessAuto