Download it now!
Bug 109425 - Libreoffice Notebookbar is not exposing accessible events needed for screen reader users.
Summary: Libreoffice Notebookbar is not exposing accessible events needed for screen r...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.0.beta1
Hardware: Other other
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.5.0 target:6.4.0.1 target:6.3.5
Keywords: accessibility, bibisected, bisected, implementationError, regression
Depends on:
Blocks: Notebookbar-a11y
  Show dependency treegraph
 
Reported: 2017-07-27 08:28 UTC by zahra
Modified: 2020-08-07 14:16 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zahra 2017-07-27 08:28:14 UTC
Description:
hello every one.
i heard about muffin in libreoffice which is activated by checking experimental features in tools, options, advance and also notebookbar in view menu and toolbars.
i heard in the users mailing lists that its similar to ribbon menus in microsoft office!
i have one question.
do you make ribbon menus for all users default option? 
and also do you remove classic menu to have only ribbon like microsoft office in the future version of libreoffice?


Steps to Reproduce:
1- in tools, options and advance activate Enable experimental features (may be unstable) and press okay.
2- in view menu and tools activate notebookbar.
3- activate nvda screen reader and try to access ribbon menus!

Actual Results:  
ribbon menus are not accessible for screen readers and in general by using keyboard.

Expected Results:
ribbon menus should be accessible via keyboard.


Reproducible: Always

User Profile Reset: no

Additional Info:
i use windows xp 32bit, nvda 2016.4 and 2017.1
firefox 52 and i tested this problem with libreoffice 5.3.4, but i am sure thats a problem since introducing of notebookbar in version 5.3


User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 zahra 2017-07-31 03:59:21 UTC
hello.
today i tested libreoffice 5.4.0 and the ribbon menus (notebookbars) is still completely inaccessible for screen reader users.
Comment 2 Heiko Tietze 2017-08-01 10:54:26 UTC
(In reply to zahra from comment #0)
> do you make ribbon menus for all users default option? 

The classic toolbar will remain the default. We don't plan to remove it.
https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the-restrictions-of-toolbars/

And since the Notebookbar is an alternative control aiming for individualization I would refrain from making all variants as accessible as possible. But that's a question for the whole team. Opinions?
Comment 3 zahra 2017-08-01 14:50:35 UTC
(In reply to Heiko Tietze from comment #2)
> (In reply to zahra from comment #0)
> > do you make ribbon menus for all users default option? 
> 
> The classic toolbar will remain the default. We don't plan to remove it.
> https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the-
> restrictions-of-toolbars/
> 
> And since the Notebookbar is an alternative control aiming for
> individualization I would refrain from making all variants as accessible as
> possible. But that's a question for the whole team. Opinions?

hello.
thanks so much for your answer and the link which you provided me.
i was worried that libreoffice becomes like microsoft office with ribbon menu not classic one.
i studied the link and bug reported related to it.
i realized that my bug is duplicate of bug
https://bugs.documentfoundation.org/show_bug.cgi?id=102059
thanks so much for your great program.
i realy appreciate you, pray sincerely in my daily five times prayers and request divine infinite mercy and blessings for you.
Comment 4 V Stuart Foote 2017-08-01 15:58:33 UTC
(In reply to Heiko Tietze from comment #2)

> And since the Notebookbar is an alternative control aiming for
> individualization I would refrain from making all variants as accessible as
> possible. But that's a question for the whole team. Opinions?

Sorry, but we don't get to make that call Heiko--correct implementation of assistive technology is _required_ across the UI but fortunately is simple to implement in UI.

We have rudimentary a11y support but are limited to F6 and TAB cycling. 

Mnemonics, with tooltips are provided but they are not exposed correctly as accessible events/targets while navigating with an AT.

@Kendy, @Szymon?
Comment 5 zahra 2017-08-01 16:14:13 UTC
(In reply to Heiko Tietze from comment #2)
> (In reply to zahra from comment #0)
> > do you make ribbon menus for all users default option? 
> 
> The classic toolbar will remain the default. We don't plan to remove it.
> https://design.blog.documentfoundation.org/2016/12/21/evolving-past-the-
> restrictions-of-toolbars/
> 
> And since the Notebookbar is an alternative control aiming for
> individualization I would refrain from making all variants as accessible as
> possible. But that's a question for the whole team. Opinions?

today i also tested libreoffice 5.4 and could not use f10 to use ribbon and f6 for navigation.
also tab does not work for me and ribbon menus are completely inaccessible for me using keyboard.
Comment 6 zahra 2017-08-01 16:17:30 UTC
(In reply to V Stuart Foote from comment #4)
> (In reply to Heiko Tietze from comment #2)
> 
> > And since the Notebookbar is an alternative control aiming for
> > individualization I would refrain from making all variants as accessible as
> > possible. But that's a question for the whole team. Opinions?
> 
> Sorry, but we don't get to make that call Heiko--correct implementation of
> assistive technology is _required_ across the UI but fortunately is simple
> to implement in UI.
> 
> We have rudimentary a11y support but are limited to F6 and TAB cycling. 
> 
> Mnemonics, with tooltips are provided but they are not exposed correctly as
> accessible events/targets while navigating with an AT.
> 
> @Kendy, @Szymon?

hi stuart.
thanks so much for your reporting bug 102059 and your supporting for screen reader users!
i pray for you every day and wish divine infinite mercy for you.
Comment 7 V Stuart Foote 2017-08-01 16:46:41 UTC
(In reply to zahra from comment #5)
> today i also tested libreoffice 5.4 and could not use f10 to use ribbon and
> f6 for navigation.
> also tab does not work for me and ribbon menus are completely inaccessible
> for me using keyboard.

Zahra, please do not call it a Ribbon, that is a completely different proprietary Microsoft desktop API that we steer away from. 

As implemented in LibreOffice across all platforms--as part of our MUFFIN (My User Friendly & Flexible INterface)--the Notebookbars are alternative user interfaces to our traditional Menus and Toolbars. They also complement our Sidebar deck and its context menu GUI.

The underlying controls are common--so current lack of exposure as accessible events is an implementation issue. And that will have to be corrected before the MUFFIN Notebookbar(s)--there are five currently--are removed from their experimental status probably at the 6.0.0 release.

Otherwise the F10, F6 cycling of bug 102059 has been corrected. And normal keyboard navigation with TAB and Cursor movement between notebookbar widgets functions correctly, and tooltips are present on mouseover or for use with AT when exposed.
Comment 8 Heiko Tietze 2017-08-01 18:32:44 UTC
(In reply to V Stuart Foote from comment #4)
> ...correct implementation of
> assistive technology is _required_ across the UI but fortunately is simple
> to implement in UI.

We could understand MUFFIN in a way to create a Notebookbar variant explicitly focusing on accessibility. On the other hand we clearly defined the minimum requirements for keyboard interaction https://wiki.documentfoundation.org/Design/SideBar
Comment 9 V Stuart Foote 2017-08-01 19:58:35 UTC
(In reply to Heiko Tietze from comment #8)
> (In reply to V Stuart Foote from comment #4)
> > ...correct implementation of
> > assistive technology is _required_ across the UI but fortunately is simple
> > to implement in UI.
> 
> We could understand MUFFIN in a way to create a Notebookbar variant
> explicitly focusing on accessibility. 

Separate implementations for Accessibility is not an answer, that is not how we or any application supports a11y. Instead we provide framework for effective keyboard navigation and then attach accessible events across the UI. The integrated accessible events for components of the Notebookbar are missing.

> On the other hand we clearly defined
> the minimum requirements for keyboard interaction
> https://wiki.documentfoundation.org/Design/SideBar

Sure and keyboard navigation on the Notebookbar(s) are mostly correct, but even if keyboard navigation is sequenced correctly with no traps or dropouts, we need to correctly implement our existing support for GetAccessible() event handling of each widget. Also need to ensure correct packing order for TAB sequence across the Notebookbar(s), and support our use of Tooltips as annotation exposed to the AT. Picking up the accelerators and any defined short-cuts would just be gravy for an improved UX for a11y dependent users.

This remains to be fixed on all of the Notebookbar flavors for MUFFIN interface.
Comment 10 Heiko Tietze 2018-06-08 08:22:04 UTC
Is this issue tackled in the current GSoC project?

(Removing UX)
Comment 11 Szymon Kłos 2018-06-13 08:28:05 UTC
(In reply to Heiko Tietze from comment #10)
> Is this issue tackled in the current GSoC project?
> 
> (Removing UX)

We will at least try to fix that I think.
Comment 12 QA Administrators 2019-11-16 03:41:06 UTC Comment hidden (obsolete)
Comment 13 V Stuart Foote 2019-11-16 05:55:10 UTC
On Windows 10 Home 64-bit en-US (1903) with NVDA 2019.1 and
Version: 6.3.3.2 (x64)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

and current master/6.5.0
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 8c85782bbe46963e2be32c3cb406982f1790fc2f
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded


Issue remains. And, if anything triggering of accessible events for a11y of the NB has gotten worse.

Controls of the Notebookbar UI do not respond with accessible events. F10, F6 cycling is spotty. And there are keyboard navigation traps moving between control groupings. While no movement on bug 107343, leave a11y dependent users with no way to restore Main menu bar and its sounding keyboard navigation. 

The Contextual single Notebookbar mode can not be reached with keyboard only navigation.

In short--it is not suitable to task and really needs dev attention.
Comment 14 Jim Raykowski 2019-11-22 08:07:18 UTC
(In reply to V Stuart Foote from comment #13)

> The Contextual single Notebookbar mode can not be reached with keyboard only
> navigation.

Commit d6e8e41c22023bc15cc4c9659b33c1cc3d6edb75 changed many of the sfxlo-NotebookbarToolBox objects can_focus property from true to false. This caused notebook bars to lose ability to access many items using tab and arrow keys.
Comment 15 Heiko Tietze 2019-11-22 08:11:17 UTC
(In reply to Jim Raykowski from comment #14)
> Commit d6e8e41c22023bc15cc4c9659b33c1cc3d6edb75 changed many of the
> sfxlo-NotebookbarToolBox objects can_focus property from true to false. 

Andreas, this was your patch. Please take a look.
Comment 16 andreas_k 2019-11-26 21:27:39 UTC
https://gerrit.libreoffice.org/#/c/83626/
Comment 17 Commit Notification 2019-11-27 07:01:47 UTC
andreas kainz committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b521f14f7c253113061798cb58fc3e565e92cb7d

tdf#109425 NB accessibility event fix

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2019-11-27 08:06:46 UTC
andreas kainz committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/bc97c1c01807c304e67a42f2e0b4abb01f8702c7

tdf#109425 NB accessibility event fix

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Heiko Tietze 2019-11-27 08:21:59 UTC
Is it resolved:fixed now?
Comment 20 Commit Notification 2019-11-27 16:45:43 UTC
andreas kainz committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/2dba53d70e857be7161ba57de1a9e5a4f8fb9851

tdf#109425 NB accessibility event fix

It will be available in 6.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Jim Raykowski 2019-11-29 02:58:40 UTC
Hi Andreas, I should have jumped in earlier to let you know I was testing the patches.

Here are some concerns I've found with Notebookbar_single.ui

1) I think Default-Grow and Default-Shrink buttons need to be visible.

2) Draw-FormatArea button does the same action as Draw-FormatArea2 button. There is differences in visible when horizontal/vertical and icon. Are both required?

3) Similar to 2, Grapic-GraphicDialog1 button does the same action as Graphic-GraphicDialog button in the GraphicContainer

4) Print preview only shows undo and paste buttons. To show all the buttons in the print container the visible property needs to be set to True. I haven't investigated why it is required in the .ui file to be set visible for the PrintContainer and not for the other containers. 
<object class="sfxlo-PriorityMergedHBox" id="PrintContainer">
                    <property name="visible">True</property>

5) Crash occurs in print preview when Close Preview button is pressed - can be reproduced in previous versions.

I don't know much about XContextChangeEventMultiplexer addContextChangeEventListener which seems to be the cause of the crash. cssl::IllegalArgumentException("listener added twice", static_cast<XWeak*>(this), 0) get thrown. To work around this one or the other places illustrated below can be commented out. Hopefully someone with knowledge about this will find the following helpful.
 

sfx2/source/notebookbar/SfxNotebookBar.cxx
bool SfxNotebookBar::StateMethod(SystemWindow* pSysWindow,
                                 const Reference<css::frame::XFrame>& xFrame,
                                 const OUString& rUIFile, bool bReloadNotebookbar)
{
...
            SfxViewFrame* pView = SfxViewFrame::Current();

            if(pView)
            {
                Reference<XContextChangeEventMultiplexer> xMultiplexer
                            = ContextChangeEventMultiplexer::get( xContext );

                if(xFrame.is())
                {
--->                xMultiplexer->addContextChangeEventListener(
                                        pNotebookBar->getContextChangeEventListener(),
                                        xFrame->getController());
                }
            }
        }

        return true;
    }

vcl/source/control/notebookbar.cxx
void NotebookBar::ControlListener(bool bListen)
{
    if(bListen)
    {
        // remove listeners
        css::uno::Reference<css::ui::XContextChangeEventMultiplexer> xMultiplexer (css::ui::ContextChangeEventMultiplexer::get(
                ::comphelper::getProcessComponentContext()));
        xMultiplexer->removeContextChangeEventListener(getContextChangeEventListener(),mxFrame->getController());
    }
// remove this else block or comment out below in the SwPagePreview destructor and crash doesn't happen
    else
    {
        // add listeners
        css::uno::Reference<css::ui::XContextChangeEventMultiplexer> xMultiplexer (css::ui::ContextChangeEventMultiplexer::get(
                ::comphelper::getProcessComponentContext()));
--->    xMultiplexer->addContextChangeEventListener(getContextChangeEventListener(),mxFrame->getController());
    }
}

sw/source/uibase/uiview/pview.cxx
SwPagePreview::~SwPagePreview()
{
    SetWindow( nullptr );
    SwViewShell* pVShell =  m_pViewWin->GetViewShell();
    pVShell->SetWin(nullptr);
    delete pVShell;

    m_pViewWin.disposeAndClear();
//    if (SfxViewFrame* pCurrent = SfxViewFrame::Current())
//        if (auto& pBar = pCurrent->GetWindow().GetSystemWindow()->GetNotebookBar())
//--->        pBar->ControlListener(false);
    m_pScrollFill.disposeAndClear();
    m_pHScrollbar.disposeAndClear();
    m_pVScrollbar.disposeAndClear();
}

framework/source/services/ContextChangeEventMultiplexer.cxx
// XContextChangeEventMultiplexer
void SAL_CALL ContextChangeEventMultiplexer::addContextChangeEventListener (
    const cssu::Reference<css::ui::XContextChangeEventListener>& rxListener,
    const cssu::Reference<cssu::XInterface>& rxEventFocus)
{
    if ( ! rxListener.is())
        throw css::lang::IllegalArgumentException(
            "can not add an empty reference",
            static_cast<XWeak*>(this),
            0);

    FocusDescriptor* pFocusDescriptor = GetFocusDescriptor(rxEventFocus, true);
    if (pFocusDescriptor != nullptr)
    {
        ListenerContainer& rContainer (pFocusDescriptor->maListeners);
        if (::std::find(rContainer.begin(), rContainer.end(), rxListener) != rContainer.end())
        {
            // The listener was added for the same event focus
            // previously.  That is an error.
--->        throw cssl::IllegalArgumentException("listener added twice", static_cast<XWeak*>(this), 0);
        }
        rContainer.push_back(rxListener);
    }
Comment 22 Jim Raykowski 2019-11-30 07:00:12 UTC
Here is a patch to provide keyboard access to the grow and shrink buttons in notebookbar contextual single and to show print preview controls.

https://gerrit.libreoffice.org/#/c/84105/
Comment 23 Jim Raykowski 2019-11-30 07:03:44 UTC
Here is a patch to make the send mail button keyboard accessible in the notebookbar tabbed compact tools tab:

https://gerrit.libreoffice.org/#/c/84101/
Comment 24 Jim Raykowski 2019-11-30 07:10:22 UTC
This patch makes Before Text Indent, After Text Indent, Above Paragraph Spacing and Below Paragraph Spacing controls used in notebookbar tabbed compact layout focus correctly when using keyboard navigation. It also corrects images used for before, after, and above controls.

https://gerrit.libreoffice.org/#/c/84103/
Comment 25 Commit Notification 2019-12-01 15:15:55 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d428f1e91575e743b624ec67699bc5b967889ca6

tdf#109425 Fixes for notebookbar single

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 Commit Notification 2019-12-01 15:18:05 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9a564c80ad48c116c261f37fea003c170ada14c4

tdf#109425 NB bar compact: Make send mail button kb accessible

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 andreas_k 2019-12-01 15:19:18 UTC
Thanks Jim. Do you have also an view on other NB layouts?
Comment 28 Commit Notification 2019-12-01 15:20:17 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/65d3285536e3342c2b1b669d0dc8c134bc7254c6

tdf#109425 Make paraspacing windows grab focus

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 V Stuart Foote 2019-12-01 17:00:39 UTC
@Jim, Andreas

On todays 2019-12-01 TB77 build of master with 
https://gerrit.libreoffice.org/#/c/83626/

Sorry but things are still not functioning well for keyboard navigation of the Notebookbar (NB), and corresponding a11y focus events are not being exposed.

Also, basic F10, and F6 navigation into the NB remains defective.

With NB defults to hide the Main menu, an F10 issued now places focus outside the LO app on its app frame, and AT sounds 'System subMenu' for its focus and of course F6 has no valid action at that point.

Seems bug 107343 needs some love. With Main Menu closed, an F10 action either needs to land on the NB, or expose the Main menu and proceed to focus there. 

The more consistent action for F10--i.e. _always_ land on the main menu, exposing it if need be. And then correct F6 navigation to enter the NB.
Comment 30 Jim Raykowski 2019-12-02 04:10:25 UTC
(In reply to andreas_k from comment #27)
> Thanks Jim. Do you have also an view on other NB layouts?

Here is some keyboard navigation help for groupedbar compact:
https://gerrit.libreoffice.org/#/c/84185/
Comment 31 andreas_k 2019-12-02 07:22:52 UTC
Hi Jim

I do update the different ui Files (a bit late) for the 6.4 release. So maybe we can work somehow closer together. You can find me in the libreoffice-design channel.

I have to update the ui files to use the customize feature from our gsoc student.
Comment 32 Commit Notification 2019-12-02 09:21:31 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/83b4c4373e1d68f79fcf841799db21320297fc88

tdf#109425 Fixes for notebookbar single

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 33 Commit Notification 2019-12-02 09:21:42 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/6e1f57551935250c45eb0c1c868f5d24842a5389

tdf#109425 NB bar compact: Make send mail button kb accessible

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 34 Commit Notification 2019-12-02 09:21:50 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/9d55361562602a420103e28dfacac8f4d80ab1db

tdf#109425 Make paraspacing windows grab focus

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 35 Commit Notification 2019-12-02 15:28:43 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/eb80ba799667973c3872904b3407a17ca3f6564a

tdf#109425 KB navigation fixes for NB groupedbar compact

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 36 Commit Notification 2019-12-02 19:21:03 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/260c50e252abf6f4d523d9ed1c11fa407277087f

tdf#109425 KB navigation fixes for NB groupedbar compact

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 37 Commit Notification 2019-12-05 06:54:50 UTC
andreas kainz committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/328c9a674057759f616c584a8ae75ca018d10fdc

tdf#109425 NB tabbed accessible for screen reader users

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Commit Notification 2019-12-05 12:06:01 UTC
andreas kainz committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/6d8cc82c8340b80a690a3aaea380b964d15d7ff1

tdf#109425 NB tabbed accessible for screen reader users

It will be available in 6.4.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 39 V Stuart Foote 2019-12-06 05:52:06 UTC
@Andreas, Jim, *

So testing on Windows 10 Home 64-bit en-US with NVDA 2019.2 and todays TB77
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 790b5de8941d8f8d98c73ed1343289d7220211ad
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

The additional GTK Focus events have restored reasonable keyboard navigation to the NB, had a few sequencing issues within groupings, but so much closer now. Thanks!

But for some reason the focus A11Y 'accessible events' are not fired when advancing through the NB in its nested position in the app frame.  But if you reduce the width of the frame, collapsing the NB, the popup bar exposed with the 'chevrons' exposes all of the accessible events.

What is different between controls held on the NB, versus the same controls held in the overflow 'chevrons' popup that allows the UNO controls 'accessible event' to fire?

And otherwise, continue to have issues with a non-functional F10 & F6 movements when the main menubar is not exposed. Seems too fragile, and prone to losing track of position in the UI.  No recovery with keyboard, requiring a blind mouse click into the document canvas to recover focus.
Comment 40 V Stuart Foote 2019-12-21 16:52:40 UTC
Issues remain on Windows 10 with NVDA screen reader and
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 209fc9fd7fa433947af0bf86e210d73fa7f5a045
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Hidden Infobar landing resolved for bug 105518, but the NB is a black hole for UX when dependent on AT tools and keyboard navigation. And without reliable <F10> action(s) we are sending users out of frame with no <Esc> or <Ctrl><F6> keyboard recovery ( bug 107343 ).
Comment 41 V Stuart Foote 2020-08-07 14:16:10 UTC
Issue of no exposed 'accessible events' continues on Windows with NVDA (2019.3.1) and Version: 7.0.0.3 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded