From fabrice.luneau76 at gmail.com  Thu Feb  5 16:55:05 2015
From: fabrice.luneau76 at gmail.com (LUNEAU Fabrice)
Date: Thu, 05 Feb 2015 16:55:05 +0100
Subject: [Accessibility] Accessibility Digest, Vol 8, Issue 6
In-Reply-To: <mailman.5.1422615601.11700.accessibility@qt-project.org>
References: <mailman.5.1422615601.11700.accessibility@qt-project.org>
Message-ID: <54D39259.8050200@gmail.com>

Bonjour,

Yes, in fact Many developers don't have a braille display, .
But many blind to, it s very expensive 4000€ for a typycal personnal  { 
device.
We count that it costs 100 €  for each cells.
But you don't need a braille display,  to test accessibility.
Personnaly I yse very few the mine.
There are some mad blinds, who use only braille display, with linux on 
text mode.

About software you can use Jaws for free during 45 minutes sessions
It is enough for testing, your work.
And after you just need to restart.
There are some problems with Windows 8.1, which  is never realy stoped.
I have never used windows eye, in France the blind learn Jaws and NVDA 
at school.
I have no idea aabout other countries, but  Jaws and  Zoom Text seems 
the most used software by visual defficient in the world.

Cordialement
Fabrice
Le 30/01/2015 12:00, accessibility-request at qt-project.org a écrit :
> Send Accessibility mailing list submissions to
> 	accessibility at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/accessibility
> or, via email, send a message with subject or body 'help' to
> 	accessibility-request at qt-project.org
>
> You can reach the person managing the list at
> 	accessibility-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Accessibility digest..."
>
>
> Today's Topics:
>
>     1. Re: Accessibility Digest, Vol 8, Issue 3 (Steve C)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Jan 2015 18:03:53 +0000
> From: Steve C <list15 at trumpton.org.uk>
> Subject: Re: [Accessibility] Accessibility Digest, Vol 8, Issue 3
> To: accessibility at qt-project.org
> Message-ID: <6442489.xRWF4c9HTQ at dime>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thursday 29 January 2015 17:32:15 LUNEAU Fabrice wrote:
>> Ok,  just a question..
>> To make sure that your inteface is fully accessible, do you turn off
>> your display and use NVDA or Jaws ? ;P
>> I say it, when an another developpers say me that  work is accessible.
>> "Try again without screen"
> I would recommend installing a screen-reader - you need to be aware that the
> voice and braille outputs are not driven from the same information source, and
> there can be scenarios (usually bugs) where one works and the other one
> doesn't - so it is good to check both.
>
> Many developers don't have a braille display, but most screen-readers have an
> emulator as a bolt-on.  Jaws and Windows Eyes have this feature, but will only
> run for a month, then for 20 minutes or so without a reboot (licensing).
>
> NVDA is free, and there is a python add-in you can use to display what would
> be on a braille display.  Note that NVDA displays the actual braille, whereas
> Jaws and WIndows Eyes show the text as normal characters.
>
> Note also that if you want you application to work with all screen-readers,
> you need to test it with more than one.  NVDA is by far the best supported, so
> I'd start with that one.
>
> Steve
>
> For the NVDA Braille Vierwe, Copy ...
> https://dl.dropboxusercontent.com/u/28976681/brailleViewer.py?dl=1
>   ... into brailleDisplayDrivers directory inside the user
> configuration directory; e.g. %appdata%\nvda\brailleDisplayDrivers
>
>
>
> ------------------------------
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>
>
> End of Accessibility Digest, Vol 8, Issue 6
> *******************************************



From jpwhiting at kde.org  Wed Feb 11 02:19:03 2015
From: jpwhiting at kde.org (Jeremy Whiting)
Date: Tue, 10 Feb 2015 18:19:03 -0700
Subject: [Accessibility] Synthesizer choice api
Message-ID: <CADWV2K5HtaiBjCuMHvVpC+KPy1rPmMNvT6qGt2sreySaf1c61g@mail.gmail.com>

Hey all,

Today I took another look at qtexttospeech_unix.cpp and realized we are
only exposing the default speech dispatcher output module's voices to the
api. I think either one of two things needs to happen. Which sounds more
usable?

1. When the backend starts up it not only gets the output modules and
create a QVoice for each one. This would require QVoice to have additional
data about which output module it is using, but wouldn't require any api to
switch output modules, just switch voices and it would switch the output
module for you.

2. Add api to QTextToSpeech to get and set the synthesizer. Whenever the
synthesizer is set the list of QVoice objects (availableVoices) will likely
change, but QVoice itself wouldn't need to contain which synthesizer the
voice is for.

I'm a bit torn myself, I think 1 is a better fit for the unix backend, but
it's probably not as usable/meaningful on other platforms. Though maybe all
platforms QVoice will need to have custom data associated with it, so we
could add a QVariant or something to QVoice to hold it.

thoughts?

thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150210/06844820/attachment.html>

From vernocte at gmail.com  Sat Feb 14 11:16:55 2015
From: vernocte at gmail.com (verum nocte)
Date: Sat, 14 Feb 2015 11:16:55 +0100
Subject: [Accessibility] Synthesizer choice api
In-Reply-To: <CADWV2K5HtaiBjCuMHvVpC+KPy1rPmMNvT6qGt2sreySaf1c61g@mail.gmail.com>
References: <CADWV2K5HtaiBjCuMHvVpC+KPy1rPmMNvT6qGt2sreySaf1c61g@mail.gmail.com>
Message-ID: <CAOUqrL_cUow1zeCEcTGhuxxqpzOG4biE5mAzSRF=Oy=w11feQA@mail.gmail.com>

I am no expert at field so my reply shouldn't count for much (it is just
that noone else replied so far). I believe that general rule of a thumb in
this situations is to send as much data as needed and than deal with it
accordingly when it is needed. It is generally easier to ignore unneeded
field than get data you don't have on your disposal.

V

On Wed, Feb 11, 2015 at 2:19 AM, Jeremy Whiting <jpwhiting at kde.org> wrote:

> Hey all,
>
> Today I took another look at qtexttospeech_unix.cpp and realized we are
> only exposing the default speech dispatcher output module's voices to the
> api. I think either one of two things needs to happen. Which sounds more
> usable?
>
> 1. When the backend starts up it not only gets the output modules and
> create a QVoice for each one. This would require QVoice to have additional
> data about which output module it is using, but wouldn't require any api to
> switch output modules, just switch voices and it would switch the output
> module for you.
>
> 2. Add api to QTextToSpeech to get and set the synthesizer. Whenever the
> synthesizer is set the list of QVoice objects (availableVoices) will likely
> change, but QVoice itself wouldn't need to contain which synthesizer the
> voice is for.
>
> I'm a bit torn myself, I think 1 is a better fit for the unix backend, but
> it's probably not as usable/meaningful on other platforms. Though maybe all
> platforms QVoice will need to have custom data associated with it, so we
> could add a QVariant or something to QVoice to hold it.
>
> thoughts?
>
> thanks,
> Jeremy
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150214/70febc2f/attachment.html>

From list15 at trumpton.org.uk  Sun Feb 15 10:49:10 2015
From: list15 at trumpton.org.uk (Steve C)
Date: Sun, 15 Feb 2015 09:49:10 +0000
Subject: [Accessibility] How do you run QT / QT Apps with a Screen Reader
	and Valgrind
Message-ID: <712001269.EI8dnz3bz4@dime>


In digging around within QT, I've stumbled across a lock-up scenario that only 
exhibits itself when NVDA is running (bug reported).  Stepping through the 
code, it looks like a response to a get attributes is being corrupted, and 
looking at the code, I can't see where / how - in fact, if I step through the 
code, it doesn't get corrupted!

I'm imagining that it is caused by a memory leak elsewhere.

As far as I can read, valgrind and windows don't work together, and wine and 
NVDA don't work together.

My quesiton is: has anyone tried running a memory analyser with QT running 
alongside a windows screen reader?  if so, how?

Thanks and Regards,

Steve



From lists at nightsoul.org  Mon Feb 16 17:51:30 2015
From: lists at nightsoul.org (Marcel)
Date: Mon, 16 Feb 2015 17:51:30 +0100
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win
	8.1)
Message-ID: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735@nightsoul.org>

[Crosspost from the qt-project.org forums, didn’t receive a reply there within a week.]

Hello!

I’m trying to make our application accessible with a screenreader. A blind colleague uses JAWS, therefore I use that for testing. Reading widgets that expect user input works quite well so far, but I’m having some trouble elsewhere:

QLabels are not read at all. JAWS has a hotkey that should “read the whole window” (JAWS-Key + B), but for our application that just reads the window title and nothing else. Everything I can focus directly via tabbing is read as well – which is of course not desirable with labels.

Probably related: We have some QWizards set up. There, the QWizardPage title and description texts are used to convey most of the information concerning the wizard page’s purpose. Those texts are not read at all as well.

I have a minimal test case application[0] that has a label (not read), a button and a QLineEdit (accessibleName read fine for both). The button opens a wizard that has title and description (not read) and no further input widgets.

Do accessible applications usually have all necessary information in input widget descriptions (therefore not needing labels) or am I doing something wrong?

This is Qt 5.4 on Windows 8.1 with JAWS 16.

Greetings,
Marcel

[0] https://filetrain.de/a11ytest.zip

From frederik.gladhorn at theqtcompany.com  Tue Feb 17 11:18:16 2015
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Tue, 17 Feb 2015 11:18:16 +0100
Subject: [Accessibility] How do you run QT / QT Apps with a Screen
	Reader and Valgrind
In-Reply-To: <712001269.EI8dnz3bz4@dime>
References: <712001269.EI8dnz3bz4@dime>
Message-ID: <27938330.7ka4KFz524@frederik-thinkcentre-m93p>

Hi Steve,

On Sunday, February 15, 2015 09:49:10 AM Steve C wrote:
> In digging around within QT, I've stumbled across a lock-up scenario that
> only exhibits itself when NVDA is running (bug reported).  Stepping through
> the code, it looks like a response to a get attributes is being corrupted,
> and looking at the code, I can't see where / how - in fact, if I step
> through the code, it doesn't get corrupted!

Debuggers interfere with the program run, for example when a pointer is not 0-
initialized, you may get invalid data, but debuggers often set memory to 0.

> I'm imagining that it is caused by a memory leak elsewhere.
Leaks show as increased memory consumption, not crashes.
> 
> As far as I can read, valgrind and windows don't work together, and wine and
> NVDA don't work together.
No, I don't think this would work, running wine in valgrind won't work.
> 
> My quesiton is: has anyone tried running a memory analyser with QT running
> alongside a windows screen reader?  if so, how?
I think all Windows memory analysis tools are expensive, so either you invest, 
or you fall back to some other means of debugging. If you know the call that 
triggers it reproducibly, then you can fall back to printf/qDebug debugging 
without a debugger and narrow down where the crash happens.

Cheers,
Frederik

> 
> Thanks and Regards,
> 
> Steve
> 
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility



From frederik.gladhorn at theqtcompany.com  Tue Feb 17 11:23:53 2015
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Tue, 17 Feb 2015 11:23:53 +0100
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
	5.4/Win 8.1)
In-Reply-To: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735@nightsoul.org>
References: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735@nightsoul.org>
Message-ID: <2464698.ysFQrH11qW@frederik-thinkcentre-m93p>

On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
> [Crosspost from the qt-project.org forums, didn’t receive a reply there
> within a week.]
> 
> Hello!
> 
> I’m trying to make our application accessible with a screenreader. A blind
> colleague uses JAWS, therefore I use that for testing. Reading widgets that
> expect user input works quite well so far, but I’m having some trouble
> elsewhere:
> 
> QLabels are not read at all. JAWS has a hotkey that should “read the whole
> window” (JAWS-Key + B), but for our application that just reads the window
> title and nothing else. Everything I can focus directly via tabbing is read
> as well – which is of course not desirable with labels.
> 
> Probably related: We have some QWizards set up. There, the QWizardPage title
> and description texts are used to convey most of the information concerning
> the wizard page’s purpose. Those texts are not read at all as well.
> 
> I have a minimal test case application[0] that has a label (not read), a
> button and a QLineEdit (accessibleName read fine for both). The button
> opens a wizard that has title and description (not read) and no further
> input widgets.
> 
> Do accessible applications usually have all necessary information in input
> widget descriptions (therefore not needing labels) or am I doing something
> wrong?
> 
> This is Qt 5.4 on Windows 8.1 with JAWS 16.

QLabel should provide accessibility information (it is represented by 
QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).

It would be interesting to know if it works with NVDA (I suspect that it does, 
looking at Steve's testing. The issue seems to be that we expose the 
information in a way that JAWS either ignores it or doesn't see it at all, so 
it's a bug in Qt.

It would be great if you file a bug report (https://bugreports.qt.io) so we 
keep track of it.

Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the 
reason for it not working.

Cheers,
Frederik

> 
> Greetings,
> Marcel
> 
> [0] https://filetrain.de/a11ytest.zip
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility



From Jan-Arve.Saether at theqtcompany.com  Tue Feb 17 13:05:44 2015
From: Jan-Arve.Saether at theqtcompany.com (Saether Jan-Arve)
Date: Tue, 17 Feb 2015 12:05:44 +0000
Subject: [Accessibility] How do you run QT / QT Apps with a Screen
	Reader	and Valgrind
In-Reply-To: <712001269.EI8dnz3bz4@dime>
References: <712001269.EI8dnz3bz4@dime>
Message-ID: <1424174751716.27892@theqtcompany.com>

Hi Steve
This was a fix for a crash, but it might very well fix your issue too: https://codereview.qt-project.org/106376

________________________________________
Fra: accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org <accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org> på vegne av Steve C <list15 at trumpton.org.uk>
Sendt: 15. februar 2015 10:49
Til: accessibility at qt-project.org
Emne: [Accessibility] How do you run QT / QT Apps with a Screen Reader  and Valgrind

In digging around within QT, I've stumbled across a lock-up scenario that only
exhibits itself when NVDA is running (bug reported).  Stepping through the
code, it looks like a response to a get attributes is being corrupted, and
looking at the code, I can't see where / how - in fact, if I step through the
code, it doesn't get corrupted!

I'm imagining that it is caused by a memory leak elsewhere.

As far as I can read, valgrind and windows don't work together, and wine and
NVDA don't work together.

My quesiton is: has anyone tried running a memory analyser with QT running
alongside a windows screen reader?  if so, how?

Thanks and Regards,

Steve

_______________________________________________
Accessibility mailing list
Accessibility at qt-project.org
http://lists.qt-project.org/mailman/listinfo/accessibility


From list15 at trumpton.org.uk  Tue Feb 17 17:00:03 2015
From: list15 at trumpton.org.uk (Steve C)
Date: Tue, 17 Feb 2015 16:00:03 +0000
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
 5.4/Win 8.1)
Message-ID: <ujcilpqbpi7862bqtjii0rm5.1424188803193@email.android.com>


    

From my digging I believe that jaws uses msaa only. Is there a simple breakpoint I can put in to verify?
Steve. 

Sent from my Samsung device

-------- Original message --------
From: Frederik Gladhorn <frederik.gladhorn at theqtcompany.com> 
Date: 2015/02/17  10:23  (GMT+00:00) 
To: accessibility at qt-project.org 
Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt
 	5.4/Win 8.1) 

On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
> [Crosspost from the qt-project.org forums, didn’t receive a reply there
> within a week.]
> 
> Hello!
> 
> I’m trying to make our application accessible with a screenreader. A blind
> colleague uses JAWS, therefore I use that for testing. Reading widgets that
> expect user input works quite well so far, but I’m having some trouble
> elsewhere:
> 
> QLabels are not read at all. JAWS has a hotkey that should “read the whole
> window” (JAWS-Key + B), but for our application that just reads the window
> title and nothing else. Everything I can focus directly via tabbing is read
> as well – which is of course not desirable with labels.
> 
> Probably related: We have some QWizards set up. There, the QWizardPage title
> and description texts are used to convey most of the information concerning
> the wizard page’s purpose. Those texts are not read at all as well.
> 
> I have a minimal test case application[0] that has a label (not read), a
> button and a QLineEdit (accessibleName read fine for both). The button
> opens a wizard that has title and description (not read) and no further
> input widgets.
> 
> Do accessible applications usually have all necessary information in input
> widget descriptions (therefore not needing labels) or am I doing something
> wrong?
> 
> This is Qt 5.4 on Windows 8.1 with JAWS 16.

QLabel should provide accessibility information (it is represented by 
QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).

It would be interesting to know if it works with NVDA (I suspect that it does, 
looking at Steve's testing. The issue seems to be that we expose the 
information in a way that JAWS either ignores it or doesn't see it at all, so 
it's a bug in Qt.

It would be great if you file a bug report (https://bugreports.qt.io) so we 
keep track of it.

Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the 
reason for it not working.

Cheers,
Frederik

> 
> Greetings,
> Marcel
> 
> [0] https://filetrain.de/a11ytest.zip
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility

_______________________________________________
Accessibility mailing list
Accessibility at qt-project.org
http://lists.qt-project.org/mailman/listinfo/accessibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150217/948aed72/attachment.html>

From Jan-Arve.Saether at theqtcompany.com  Wed Feb 18 10:25:10 2015
From: Jan-Arve.Saether at theqtcompany.com (Saether Jan-Arve)
Date: Wed, 18 Feb 2015 09:25:10 +0000
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
 5.4/Win 8.1)
In-Reply-To: <ujcilpqbpi7862bqtjii0rm5.1424188803193@email.android.com>
References: <ujcilpqbpi7862bqtjii0rm5.1424188803193@email.android.com>
Message-ID: <1424251520265.34631@theqtcompany.com>

Yes.

qtbase\src\plugins\platforms\windows\accessible\iaccessible2.cpp(270)


In case the line number is not completely correct, its at the call to AddRef() inside

QWindowsIA2Accessible::QueryInterface()

I'm curious to know which interfaces it queries though (I think it queries some).

Jan Arve



________________________________
Fra: accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org <accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org> på vegne av Steve C <list15 at trumpton.org.uk>
Sendt: 17. februar 2015 17:00
Til: Gladhorn Frederik; accessibility at qt-project.org
Emne: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1)


>From my digging I believe that jaws uses msaa only. Is there a simple breakpoint I can put in to verify?

Steve.


Sent from my Samsung device


-------- Original message --------
From: Frederik Gladhorn <frederik.gladhorn at theqtcompany.com>
Date: 2015/02/17 10:23 (GMT+00:00)
To: accessibility at qt-project.org
Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1)

On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
> [Crosspost from the qt-project.org forums, didn't receive a reply there
> within a week.]
>
> Hello!
>
> I'm trying to make our application accessible with a screenreader. A blind
> colleague uses JAWS, therefore I use that for testing. Reading widgets that
> expect user input works quite well so far, but I'm having some trouble
> elsewhere:
>
> QLabels are not read at all. JAWS has a hotkey that should "read the whole
> window" (JAWS-Key + B), but for our application that just reads the window
> title and nothing else. Everything I can focus directly via tabbing is read
> as well - which is of course not desirable with labels.
>
> Probably related: We have some QWizards set up. There, the QWizardPage title
> and description texts are used to convey most of the information concerning
> the wizard page's purpose. Those texts are not read at all as well.
>
> I have a minimal test case application[0] that has a label (not read), a
> button and a QLineEdit (accessibleName read fine for both). The button
> opens a wizard that has title and description (not read) and no further
> input widgets.
>
> Do accessible applications usually have all necessary information in input
> widget descriptions (therefore not needing labels) or am I doing something
> wrong?
>
> This is Qt 5.4 on Windows 8.1 with JAWS 16.

QLabel should provide accessibility information (it is represented by
QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).

It would be interesting to know if it works with NVDA (I suspect that it does,
looking at Steve's testing. The issue seems to be that we expose the
information in a way that JAWS either ignores it or doesn't see it at all, so
it's a bug in Qt.

It would be great if you file a bug report (https://bugreports.qt.io) so we
keep track of it.

Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the
reason for it not working.

Cheers,
Frederik

>
> Greetings,
> Marcel
>
> [0] https://filetrain.de/a11ytest.zip
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility

_______________________________________________
Accessibility mailing list
Accessibility at qt-project.org
http://lists.qt-project.org/mailman/listinfo/accessibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150218/4eb5fce4/attachment.html>

From fabrice.luneau76 at gmail.com  Wed Feb 18 11:46:02 2015
From: fabrice.luneau76 at gmail.com (LUNEAU Fabrice)
Date: Wed, 18 Feb 2015 11:46:02 +0100
Subject: [Accessibility] Accessibility Digest, Vol 9, Issue 5
In-Reply-To: <mailman.7.1424170802.25748.accessibility@qt-project.org>
References: <mailman.7.1424170802.25748.accessibility@qt-project.org>
Message-ID: <54E46D6A.5090300@gmail.com>

Bonjour,

As I say previoulsy I am blind french devellopper, but in Java/J2E.
I follow the list because I plan to use Qt to test accissibility level.
However I have experience to make accessibility with Swing and other GUI

The following tip work in many cases.

In first time a label is not focusable, so Jaws or NVDA  will not able 
to read it.
A label describe an other element a field for example.
Try to find a function to join the element and the label(setLabelFor)
Or you can set up a tool tip text, for the conponent,  it works to
The last solution îs using a lield with a text, but in disabled mode.

In a second time you should give the the focus to the main window and 
after to the the first conponent focussable that yoyr user will use 
first in your application

Jaws key + b read the window as a text

Cordialement
Fabrice

A
Le 17/02/2015 12:00, accessibility-request at qt-project.org a écrit :
> Send Accessibility mailing list submissions to
> 	accessibility at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/accessibility
> or, via email, send a message with subject or body 'help' to
> 	accessibility-request at qt-project.org
>
> You can reach the person managing the list at
> 	accessibility-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Accessibility digest..."
>
>
> Today's Topics:
>
>     1. QLabels not read by JAWS screenreader (Qt 5.4/Win	8.1) (Marcel)
>     2. Re: How do you run QT / QT Apps with a Screen	Reader and
>        Valgrind (Frederik Gladhorn)
>     3. Re: QLabels not read by JAWS screenreader (Qt	5.4/Win 8.1)
>        (Frederik Gladhorn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 16 Feb 2015 17:51:30 +0100
> From: Marcel <lists at nightsoul.org>
> Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
> 	5.4/Win	8.1)
> To: accessibility at qt-project.org
> Message-ID: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735 at nightsoul.org>
> Content-Type: text/plain; charset=utf-8
>
> [Crosspost from the qt-project.org forums, didn?t receive a reply there within a week.]
>
> Hello!
>
> I?m trying to make our application accessible with a screenreader. A blind colleague uses JAWS, therefore I use that for testing. Reading widgets that expect user input works quite well so far, but I?m having some trouble elsewhere:
>
> QLabels are not read at all. JAWS has a hotkey that should ?read the whole window? (JAWS-Key + B), but for our application that just reads the window title and nothing else. Everything I can focus directly via tabbing is read as well ? which is of course not desirable with labels.
>
> Probably related: We have some QWizards set up. There, the QWizardPage title and description texts are used to convey most of the information concerning the wizard page?s purpose. Those texts are not read at all as well.
>
> I have a minimal test case application[0] that has a label (not read), a button and a QLineEdit (accessibleName read fine for both). The button opens a wizard that has title and description (not read) and no further input widgets.
>
> Do accessible applications usually have all necessary information in input widget descriptions (therefore not needing labels) or am I doing something wrong?
>
> This is Qt 5.4 on Windows 8.1 with JAWS 16.
>
> Greetings,
> Marcel
>
> [0] https://filetrain.de/a11ytest.zip
>
> ------------------------------
>
> Message: 2
> Date: Tue, 17 Feb 2015 11:18:16 +0100
> From: Frederik Gladhorn <frederik.gladhorn at theqtcompany.com>
> Subject: Re: [Accessibility] How do you run QT / QT Apps with a Screen
> 	Reader and Valgrind
> To: <accessibility at qt-project.org>
> Message-ID: <27938330.7ka4KFz524 at frederik-thinkcentre-m93p>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Steve,
>
> On Sunday, February 15, 2015 09:49:10 AM Steve C wrote:
>> In digging around within QT, I've stumbled across a lock-up scenario that
>> only exhibits itself when NVDA is running (bug reported).  Stepping through
>> the code, it looks like a response to a get attributes is being corrupted,
>> and looking at the code, I can't see where / how - in fact, if I step
>> through the code, it doesn't get corrupted!
> Debuggers interfere with the program run, for example when a pointer is not 0-
> initialized, you may get invalid data, but debuggers often set memory to 0.
>
>> I'm imagining that it is caused by a memory leak elsewhere.
> Leaks show as increased memory consumption, not crashes.
>> As far as I can read, valgrind and windows don't work together, and wine and
>> NVDA don't work together.
> No, I don't think this would work, running wine in valgrind won't work.
>> My quesiton is: has anyone tried running a memory analyser with QT running
>> alongside a windows screen reader?  if so, how?
> I think all Windows memory analysis tools are expensive, so either you invest,
> or you fall back to some other means of debugging. If you know the call that
> triggers it reproducibly, then you can fall back to printf/qDebug debugging
> without a debugger and narrow down where the crash happens.
>
> Cheers,
> Frederik
>
>> Thanks and Regards,
>>
>> Steve
>>
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 17 Feb 2015 11:23:53 +0100
> From: Frederik Gladhorn <frederik.gladhorn at theqtcompany.com>
> Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt
> 	5.4/Win 8.1)
> To: <accessibility at qt-project.org>
> Message-ID: <2464698.ysFQrH11qW at frederik-thinkcentre-m93p>
> Content-Type: text/plain; charset="utf-8"
>
> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>> [Crosspost from the qt-project.org forums, didn?t receive a reply there
>> within a week.]
>>
>> Hello!
>>
>> I?m trying to make our application accessible with a screenreader. A blind
>> colleague uses JAWS, therefore I use that for testing. Reading widgets that
>> expect user input works quite well so far, but I?m having some trouble
>> elsewhere:
>>
>> QLabels are not read at all. JAWS has a hotkey that should ?read the whole
>> window? (JAWS-Key + B), but for our application that just reads the window
>> title and nothing else. Everything I can focus directly via tabbing is read
>> as well ? which is of course not desirable with labels.
>>
>> Probably related: We have some QWizards set up. There, the QWizardPage title
>> and description texts are used to convey most of the information concerning
>> the wizard page?s purpose. Those texts are not read at all as well.
>>
>> I have a minimal test case application[0] that has a label (not read), a
>> button and a QLineEdit (accessibleName read fine for both). The button
>> opens a wizard that has title and description (not read) and no further
>> input widgets.
>>
>> Do accessible applications usually have all necessary information in input
>> widget descriptions (therefore not needing labels) or am I doing something
>> wrong?
>>
>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
> QLabel should provide accessibility information (it is represented by
> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
>
> It would be interesting to know if it works with NVDA (I suspect that it does,
> looking at Steve's testing. The issue seems to be that we expose the
> information in a way that JAWS either ignores it or doesn't see it at all, so
> it's a bug in Qt.
>
> It would be great if you file a bug report (https://bugreports.qt.io) so we
> keep track of it.
>
> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the
> reason for it not working.
>
> Cheers,
> Frederik
>
>> Greetings,
>> Marcel
>>
>> [0] https://filetrain.de/a11ytest.zip
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility
>
>
> ------------------------------
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>
>
> End of Accessibility Digest, Vol 9, Issue 5
> *******************************************



From lists at nightsoul.org  Wed Feb 18 12:45:28 2015
From: lists at nightsoul.org (Marcel)
Date: Wed, 18 Feb 2015 12:45:28 +0100
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
	5.4/Win 8.1)
In-Reply-To: <2464698.ysFQrH11qW@frederik-thinkcentre-m93p>
References: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735@nightsoul.org>
	<2464698.ysFQrH11qW@frederik-thinkcentre-m93p>
Message-ID: <42C7D16B-5BB1-4EA0-9829-6A6DEE29B2A9@nightsoul.org>


> Am 17.02.2015 um 11:23 schrieb Frederik Gladhorn <frederik.gladhorn at theqtcompany.com>:
> 
> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>> [Crosspost from the qt-project.org forums, didn’t receive a reply there
>> within a week.]
>> 
>> Hello!
>> 
>> I’m trying to make our application accessible with a screenreader. A blind
>> colleague uses JAWS, therefore I use that for testing. Reading widgets that
>> expect user input works quite well so far, but I’m having some trouble
>> elsewhere:
>> 
>> QLabels are not read at all. JAWS has a hotkey that should “read the whole
>> window” (JAWS-Key + B), but for our application that just reads the window
>> title and nothing else. Everything I can focus directly via tabbing is read
>> as well – which is of course not desirable with labels.
>> 
>> Probably related: We have some QWizards set up. There, the QWizardPage title
>> and description texts are used to convey most of the information concerning
>> the wizard page’s purpose. Those texts are not read at all as well.
>> 
>> I have a minimal test case application[0] that has a label (not read), a
>> button and a QLineEdit (accessibleName read fine for both). The button
>> opens a wizard that has title and description (not read) and no further
>> input widgets.
>> 
>> Do accessible applications usually have all necessary information in input
>> widget descriptions (therefore not needing labels) or am I doing something
>> wrong?
>> 
>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
> 
> QLabel should provide accessibility information (it is represented by 
> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
> 
> It would be interesting to know if it works with NVDA (I suspect that it does, 
> looking at Steve's testing. The issue seems to be that we expose the 
> information in a way that JAWS either ignores it or doesn't see it at all, so 
> it's a bug in Qt.
> 
> It would be great if you file a bug report (https://bugreports.qt.io) so we 
> keep track of it.
> 
> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the 
> reason for it not working.

I have filed the report here: https://bugreports.qt.io/browse/QTBUG-44537
NVDA doesn’t read that label as well when pressing NVDA+B („read whole window“, results in *only* the window title being read) but announces it’s accessibleName and description upon mouseover.

Marcel

> 
> Cheers,
> Frederik
> 
>> 
>> Greetings,
>> Marcel
>> 
>> [0] https://filetrain.de/a11ytest.zip
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility



From list15 at trumpton.org.uk  Wed Feb 18 13:22:02 2015
From: list15 at trumpton.org.uk (Steve C)
Date: Wed, 18 Feb 2015 12:22:02 +0000
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
 5.4/Win 8.1)
Message-ID: <e1glp19wjc03sukgrqr00pt0.1424262122440@email.android.com>


    
I captured the unsupported ones in bug report 39522 but will try to capture a complete list and report here. It will probably be at the weekend though. Steve. 


Sent from my Samsung device

-------- Original message --------
From: Saether Jan-Arve <Jan-Arve.Saether at theqtcompany.com> 
Date: 2015/02/18  09:25  (GMT+00:00) 
To: Steve C <list15 at trumpton.org.uk>, Gladhorn Frederik <Frederik.Gladhorn at theqtcompany.com>, accessibility at qt-project.org 
Subject: SV: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1) 



Yes.
qtbase\src\plugins\platforms\windows\accessible\iaccessible2.cpp(270)



In case the line number is not completely correct, its at the call to AddRef() inside 
QWindowsIA2Accessible::QueryInterface()



I'm curious to know which interfaces it queries though (I think it queries some).



Jan Arve








Fra: accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org <accessibility-bounces+jan-arve.saether=theqtcompany.com at qt-project.org>
 på vegne av Steve C <list15 at trumpton.org.uk>

Sendt: 17. februar 2015 17:00

Til: Gladhorn Frederik; accessibility at qt-project.org

Emne: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1)
 





From my digging I believe that jaws uses msaa only. Is there a simple breakpoint I can put in to verify?



Steve. 







Sent from my Samsung device





-------- Original message --------

From: Frederik Gladhorn <frederik.gladhorn at theqtcompany.com> 

Date: 2015/02/17 10:23 (GMT+00:00) 

To: accessibility at qt-project.org 

Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1)




On Monday, February 16, 2015 05:51:30 PM Marcel wrote:

> [Crosspost from the qt-project.org forums, didn’t receive a reply there

> within a week.]

> 

> Hello!

> 

> I’m trying to make our application accessible with a screenreader. A blind

> colleague uses JAWS, therefore I use that for testing. Reading widgets that

> expect user input works quite well so far, but I’m having some trouble

> elsewhere:

> 

> QLabels are not read at all. JAWS has a hotkey that should “read the whole

> window” (JAWS-Key + B), but for our application that just reads the window

> title and nothing else. Everything I can focus directly via tabbing is read

> as well – which is of course not desirable with labels.

> 

> Probably related: We have some QWizards set up. There, the QWizardPage title

> and description texts are used to convey most of the information concerning

> the wizard page’s purpose. Those texts are not read at all as well.

> 

> I have a minimal test case application[0] that has a label (not read), a

> button and a QLineEdit (accessibleName read fine for both). The button

> opens a wizard that has title and description (not read) and no further

> input widgets.

> 

> Do accessible applications usually have all necessary information in input

> widget descriptions (therefore not needing labels) or am I doing something

> wrong?

> 

> This is Qt 5.4 on Windows 8.1 with JAWS 16.



QLabel should provide accessibility information (it is represented by 

QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).



It would be interesting to know if it works with NVDA (I suspect that it does, 

looking at Steve's testing. The issue seems to be that we expose the 

information in a way that JAWS either ignores it or doesn't see it at all, so 

it's a bug in Qt.



It would be great if you file a bug report (https://bugreports.qt.io) so we 

keep track of it.



Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is the 

reason for it not working.



Cheers,

Frederik



> 

> Greetings,

> Marcel

> 

> [0] https://filetrain.de/a11ytest.zip

> _______________________________________________

> Accessibility mailing list

> Accessibility at qt-project.org

> http://lists.qt-project.org/mailman/listinfo/accessibility



_______________________________________________

Accessibility mailing list

Accessibility at qt-project.org

http://lists.qt-project.org/mailman/listinfo/accessibility




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150218/11122f66/attachment.html>

From recklessplayeralpha at gmail.com  Sun Feb 22 18:54:20 2015
From: recklessplayeralpha at gmail.com (Reckless Player)
Date: Sun, 22 Feb 2015 23:24:20 +0530
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
	5.4/Win 8.1)
In-Reply-To: <42C7D16B-5BB1-4EA0-9829-6A6DEE29B2A9@nightsoul.org>
References: <C2EAF4E4-3AC7-4BBB-A1D8-5C8E333F0735@nightsoul.org>
	<2464698.ysFQrH11qW@frederik-thinkcentre-m93p>
	<42C7D16B-5BB1-4EA0-9829-6A6DEE29B2A9@nightsoul.org>
Message-ID: <CAM+xS38fwAUTZCg31tDYVw0Gu+t79mJ+FqS+kGsvvbu0_wMypQ@mail.gmail.com>

Hello,

I’m a sort of advanced user of GUI apps (of every type). I’ve been
hanging around this list for a while because I have lots of complaints
against Qt, and if time permits will air them in due course.

Focusing on the present topic, IAccessible2 has been supported by Jaws
and NVDA for a long time. Jaws and NVDA now mainly support UIA and
IAccessible2.
IAccessible2 has been used in Eclipse and SWT (QT’s sort of rival I
suppose) since Eclipse 3.6.
In fact, SWT has been the most accessible library under Windows. It
gave access to toolbars to screen reader users much before UIA
attempted to do the same.
Under MSAA, screen reader users, who are more broadly keyboard users
didn’t have access to toolbars and toolbar controls.
Even though I love Python, I lament the fact that SWT didn’t catch on,
and now is not likely to do so.

In summary, a fully accessible Qt app is like a mythical beast for me at least.
I’m not a GUI developer, but I have to write to many developers
requesting for accessibility improvements.
And because of what I have to go through, I highlight the following 2
lines that make all the difference between me have to beg developers
to make their apps accessible and being ignored; and never having to
contact them at all because nothing extra has to be done.

>From SWT:
“Most of the accessibility support is built right in to the SWT
widgets; therefore, in many cases a developer only has to use the
widgets correctly to take advantage of the full spectrum of MSAA and
IA2 capabilities.”

>From Qt (5.4):
“*only a few changes* from your side may be required to allow even
more users to enjoy it.”


On 2/18/15, Marcel <lists at nightsoul.org> wrote:
>
>> Am 17.02.2015 um 11:23 schrieb Frederik Gladhorn
>> <frederik.gladhorn at theqtcompany.com>:
>>
>> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>>> [Crosspost from the qt-project.org forums, didn’t receive a reply there
>>> within a week.]
>>>
>>> Hello!
>>>
>>> I’m trying to make our application accessible with a screenreader. A
>>> blind
>>> colleague uses JAWS, therefore I use that for testing. Reading widgets
>>> that
>>> expect user input works quite well so far, but I’m having some trouble
>>> elsewhere:
>>>
>>> QLabels are not read at all. JAWS has a hotkey that should “read the
>>> whole
>>> window” (JAWS-Key + B), but for our application that just reads the
>>> window
>>> title and nothing else. Everything I can focus directly via tabbing is
>>> read
>>> as well – which is of course not desirable with labels.
>>>
>>> Probably related: We have some QWizards set up. There, the QWizardPage
>>> title
>>> and description texts are used to convey most of the information
>>> concerning
>>> the wizard page’s purpose. Those texts are not read at all as well.
>>>
>>> I have a minimal test case application[0] that has a label (not read), a
>>> button and a QLineEdit (accessibleName read fine for both). The button
>>> opens a wizard that has title and description (not read) and no further
>>> input widgets.
>>>
>>> Do accessible applications usually have all necessary information in
>>> input
>>> widget descriptions (therefore not needing labels) or am I doing
>>> something
>>> wrong?
>>>
>>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
>>
>> QLabel should provide accessibility information (it is represented by
>> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
>>
>> It would be interesting to know if it works with NVDA (I suspect that it
>> does,
>> looking at Steve's testing. The issue seems to be that we expose the
>> information in a way that JAWS either ignores it or doesn't see it at all,
>> so
>> it's a bug in Qt.
>>
>> It would be great if you file a bug report (https://bugreports.qt.io) so
>> we
>> keep track of it.
>>
>> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is
>> the
>> reason for it not working.
>
> I have filed the report here: https://bugreports.qt.io/browse/QTBUG-44537
> NVDA doesn’t read that label as well when pressing NVDA+B („read whole
> window“, results in *only* the window title being read) but announces it’s
> accessibleName and description upon mouseover.
>
> Marcel
>
>>
>> Cheers,
>> Frederik
>>
>>>
>>> Greetings,
>>> Marcel
>>>
>>> [0] https://filetrain.de/a11ytest.zip
>>> _______________________________________________
>>> Accessibility mailing list
>>> Accessibility at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/accessibility
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>


-- 
Peace
RP


From list15 at trumpton.org.uk  Mon Feb 23 10:22:13 2015
From: list15 at trumpton.org.uk (Steve C)
Date: Mon, 23 Feb 2015 09:22:13 +0000
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
 5.4/Win 8.1)
Message-ID: <uvxtmvynx4hgck3dve3nnd2f.1424683333825@email.android.com>


    


I agree that qt is not there yet however with our feedback it can be. The sheer number of different platforms that qt supports makes it a very attractive system. 
The qt accessibility is now enabled by default and the same statement you have written for swt also applies to qt.
Steve Clarke ... just another library user. 



Sent from my Samsung device

-------- Original message --------
From: Reckless Player <recklessplayeralpha at gmail.com> 
Date: 2015/02/22  17:54  (GMT+00:00) 
To: accessibility at qt-project.org 
Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt
 	5.4/Win 8.1) 

Hello,

I’m a sort of advanced user of GUI apps (of every type). I’ve been
hanging around this list for a while because I have lots of complaints
against Qt, and if time permits will air them in due course.

Focusing on the present topic, IAccessible2 has been supported by Jaws
and NVDA for a long time. Jaws and NVDA now mainly support UIA and
IAccessible2.
IAccessible2 has been used in Eclipse and SWT (QT’s sort of rival I
suppose) since Eclipse 3.6.
In fact, SWT has been the most accessible library under Windows. It
gave access to toolbars to screen reader users much before UIA
attempted to do the same.
Under MSAA, screen reader users, who are more broadly keyboard users
didn’t have access to toolbars and toolbar controls.
Even though I love Python, I lament the fact that SWT didn’t catch on,
and now is not likely to do so.

In summary, a fully accessible Qt app is like a mythical beast for me at least.
I’m not a GUI developer, but I have to write to many developers
requesting for accessibility improvements.
And because of what I have to go through, I highlight the following 2
lines that make all the difference between me have to beg developers
to make their apps accessible and being ignored; and never having to
contact them at all because nothing extra has to be done.

From SWT:
“Most of the accessibility support is built right in to the SWT
widgets; therefore, in many cases a developer only has to use the
widgets correctly to take advantage of the full spectrum of MSAA and
IA2 capabilities.”

From Qt (5.4):
“*only a few changes* from your side may be required to allow even
more users to enjoy it.”


On 2/18/15, Marcel <lists at nightsoul.org> wrote:
>
>> Am 17.02.2015 um 11:23 schrieb Frederik Gladhorn
>> <frederik.gladhorn at theqtcompany.com>:
>>
>> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>>> [Crosspost from the qt-project.org forums, didn’t receive a reply there
>>> within a week.]
>>>
>>> Hello!
>>>
>>> I’m trying to make our application accessible with a screenreader. A
>>> blind
>>> colleague uses JAWS, therefore I use that for testing. Reading widgets
>>> that
>>> expect user input works quite well so far, but I’m having some trouble
>>> elsewhere:
>>>
>>> QLabels are not read at all. JAWS has a hotkey that should “read the
>>> whole
>>> window” (JAWS-Key + B), but for our application that just reads the
>>> window
>>> title and nothing else. Everything I can focus directly via tabbing is
>>> read
>>> as well – which is of course not desirable with labels.
>>>
>>> Probably related: We have some QWizards set up. There, the QWizardPage
>>> title
>>> and description texts are used to convey most of the information
>>> concerning
>>> the wizard page’s purpose. Those texts are not read at all as well.
>>>
>>> I have a minimal test case application[0] that has a label (not read), a
>>> button and a QLineEdit (accessibleName read fine for both). The button
>>> opens a wizard that has title and description (not read) and no further
>>> input widgets.
>>>
>>> Do accessible applications usually have all necessary information in
>>> input
>>> widget descriptions (therefore not needing labels) or am I doing
>>> something
>>> wrong?
>>>
>>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
>>
>> QLabel should provide accessibility information (it is represented by
>> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
>>
>> It would be interesting to know if it works with NVDA (I suspect that it
>> does,
>> looking at Steve's testing. The issue seems to be that we expose the
>> information in a way that JAWS either ignores it or doesn't see it at all,
>> so
>> it's a bug in Qt.
>>
>> It would be great if you file a bug report (https://bugreports.qt.io) so
>> we
>> keep track of it.
>>
>> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is
>> the
>> reason for it not working.
>
> I have filed the report here: https://bugreports.qt.io/browse/QTBUG-44537
> NVDA doesn’t read that label as well when pressing NVDA+B („read whole
> window“, results in *only* the window title being read) but announces it’s
> accessibleName and description upon mouseover.
>
> Marcel
>
>>
>> Cheers,
>> Frederik
>>
>>>
>>> Greetings,
>>> Marcel
>>>
>>> [0] https://filetrain.de/a11ytest.zip
>>> _______________________________________________
>>> Accessibility mailing list
>>> Accessibility at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/accessibility
>
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>


-- 
Peace
RP
_______________________________________________
Accessibility mailing list
Accessibility at qt-project.org
http://lists.qt-project.org/mailman/listinfo/accessibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/accessibility/attachments/20150223/ddfb005f/attachment.html>

From fabrice.luneau76 at gmail.com  Tue Feb 24 10:26:12 2015
From: fabrice.luneau76 at gmail.com (LUNEAU Fabrice)
Date: Tue, 24 Feb 2015 10:26:12 +0100
Subject: [Accessibility] Accessibility Digest, Vol 9, Issue 8
In-Reply-To: <mailman.5.1424689201.22859.accessibility@qt-project.org>
References: <mailman.5.1424689201.22859.accessibility@qt-project.org>
Message-ID: <54EC43B4.20208@gmail.com>

to access menu bare you can use the universal shortcut F210

Le 23/02/2015 12:00, accessibility-request at qt-project.org a écrit :
> Send Accessibility mailing list submissions to
> 	accessibility at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/accessibility
> or, via email, send a message with subject or body 'help' to
> 	accessibility-request at qt-project.org
>
> You can reach the person managing the list at
> 	accessibility-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Accessibility digest..."
>
>
> Today's Topics:
>
>     1. Re: QLabels not read by JAWS screenreader (Qt	5.4/Win 8.1)
>        (Reckless Player)
>     2. Re: QLabels not read by JAWS screenreader (Qt 5.4/Win 8.1)
>        (Steve C)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 22 Feb 2015 23:24:20 +0530
> From: Reckless Player <recklessplayeralpha at gmail.com>
> Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt
> 	5.4/Win 8.1)
> To: accessibility at qt-project.org
> Message-ID:
> 	<CAM+xS38fwAUTZCg31tDYVw0Gu+t79mJ+FqS+kGsvvbu0_wMypQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> I?m a sort of advanced user of GUI apps (of every type). I?ve been
> hanging around this list for a while because I have lots of complaints
> against Qt, and if time permits will air them in due course.
>
> Focusing on the present topic, IAccessible2 has been supported by Jaws
> and NVDA for a long time. Jaws and NVDA now mainly support UIA and
> IAccessible2.
> IAccessible2 has been used in Eclipse and SWT (QT?s sort of rival I
> suppose) since Eclipse 3.6.
> In fact, SWT has been the most accessible library under Windows. It
> gave access to toolbars to screen reader users much before UIA
> attempted to do the same.
> Under MSAA, screen reader users, who are more broadly keyboard users
> didn?t have access to toolbars and toolbar controls.
> Even though I love Python, I lament the fact that SWT didn?t catch on,
> and now is not likely to do so.
>
> In summary, a fully accessible Qt app is like a mythical beast for me at least.
> I?m not a GUI developer, but I have to write to many developers
> requesting for accessibility improvements.
> And because of what I have to go through, I highlight the following 2
> lines that make all the difference between me have to beg developers
> to make their apps accessible and being ignored; and never having to
> contact them at all because nothing extra has to be done.
>
> >From SWT:
> ?Most of the accessibility support is built right in to the SWT
> widgets; therefore, in many cases a developer only has to use the
> widgets correctly to take advantage of the full spectrum of MSAA and
> IA2 capabilities.?
>
> >From Qt (5.4):
> ?*only a few changes* from your side may be required to allow even
> more users to enjoy it.?
>
>
> On 2/18/15, Marcel <lists at nightsoul.org> wrote:
>>> Am 17.02.2015 um 11:23 schrieb Frederik Gladhorn
>>> <frederik.gladhorn at theqtcompany.com>:
>>>
>>> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>>>> [Crosspost from the qt-project.org forums, didn?t receive a reply there
>>>> within a week.]
>>>>
>>>> Hello!
>>>>
>>>> I?m trying to make our application accessible with a screenreader. A
>>>> blind
>>>> colleague uses JAWS, therefore I use that for testing. Reading widgets
>>>> that
>>>> expect user input works quite well so far, but I?m having some trouble
>>>> elsewhere:
>>>>
>>>> QLabels are not read at all. JAWS has a hotkey that should ?read the
>>>> whole
>>>> window? (JAWS-Key + B), but for our application that just reads the
>>>> window
>>>> title and nothing else. Everything I can focus directly via tabbing is
>>>> read
>>>> as well ? which is of course not desirable with labels.
>>>>
>>>> Probably related: We have some QWizards set up. There, the QWizardPage
>>>> title
>>>> and description texts are used to convey most of the information
>>>> concerning
>>>> the wizard page?s purpose. Those texts are not read at all as well.
>>>>
>>>> I have a minimal test case application[0] that has a label (not read), a
>>>> button and a QLineEdit (accessibleName read fine for both). The button
>>>> opens a wizard that has title and description (not read) and no further
>>>> input widgets.
>>>>
>>>> Do accessible applications usually have all necessary information in
>>>> input
>>>> widget descriptions (therefore not needing labels) or am I doing
>>>> something
>>>> wrong?
>>>>
>>>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
>>> QLabel should provide accessibility information (it is represented by
>>> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
>>>
>>> It would be interesting to know if it works with NVDA (I suspect that it
>>> does,
>>> looking at Steve's testing. The issue seems to be that we expose the
>>> information in a way that JAWS either ignores it or doesn't see it at all,
>>> so
>>> it's a bug in Qt.
>>>
>>> It would be great if you file a bug report (https://bugreports.qt.io) so
>>> we
>>> keep track of it.
>>>
>>> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is
>>> the
>>> reason for it not working.
>> I have filed the report here: https://bugreports.qt.io/browse/QTBUG-44537
>> NVDA doesn?t read that label as well when pressing NVDA+B (?read whole
>> window?, results in *only* the window title being read) but announces it?s
>> accessibleName and description upon mouseover.
>>
>> Marcel
>>
>>> Cheers,
>>> Frederik
>>>
>>>> Greetings,
>>>> Marcel
>>>>
>>>> [0] https://filetrain.de/a11ytest.zip
>>>> _______________________________________________
>>>> Accessibility mailing list
>>>> Accessibility at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/accessibility
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility
>>
>



From recklessplayeralpha at gmail.com  Tue Feb 24 18:16:15 2015
From: recklessplayeralpha at gmail.com (Reckless Player)
Date: Tue, 24 Feb 2015 22:46:15 +0530
Subject: [Accessibility] QLabels not read by JAWS screenreader (Qt
	5.4/Win 8.1)
In-Reply-To: <uvxtmvynx4hgck3dve3nnd2f.1424683333825@email.android.com>
References: <uvxtmvynx4hgck3dve3nnd2f.1424683333825@email.android.com>
Message-ID: <CAM+xS3-0tHYzqhsHmSRJai6n9Y6Uab+T70mXZrsbyFErOmQbWQ@mail.gmail.com>

Hello,

If you're referring to my quotes, then they are directly picked from
the documentation for developers.
Feel free to point out a single Qt app that is developed for everyone,
and is accessible without the developer paying "special attention" to
accessibility.

More generally, if newer versions of Qt are becoming increasingly
accessible, then this will only be picked up by developers if there
are dev tools encouraging upgradation.

On 2/23/15, Steve C <list15 at trumpton.org.uk> wrote:
>
>
>
>
> I agree that qt is not there yet however with our feedback it can be. The
> sheer number of different platforms that qt supports makes it a very
> attractive system.
> The qt accessibility is now enabled by default and the same statement you
> have written for swt also applies to qt.
> Steve Clarke ... just another library user.
>
>
>
> Sent from my Samsung device
>
> -------- Original message --------
> From: Reckless Player <recklessplayeralpha at gmail.com>
> Date: 2015/02/22  17:54  (GMT+00:00)
> To: accessibility at qt-project.org
> Subject: Re: [Accessibility] QLabels not read by JAWS screenreader (Qt
> 	5.4/Win 8.1)
>
> Hello,
>
> I’m a sort of advanced user of GUI apps (of every type). I’ve been
> hanging around this list for a while because I have lots of complaints
> against Qt, and if time permits will air them in due course.
>
> Focusing on the present topic, IAccessible2 has been supported by Jaws
> and NVDA for a long time. Jaws and NVDA now mainly support UIA and
> IAccessible2.
> IAccessible2 has been used in Eclipse and SWT (QT’s sort of rival I
> suppose) since Eclipse 3.6.
> In fact, SWT has been the most accessible library under Windows. It
> gave access to toolbars to screen reader users much before UIA
> attempted to do the same.
> Under MSAA, screen reader users, who are more broadly keyboard users
> didn’t have access to toolbars and toolbar controls.
> Even though I love Python, I lament the fact that SWT didn’t catch on,
> and now is not likely to do so.
>
> In summary, a fully accessible Qt app is like a mythical beast for me at
> least.
> I’m not a GUI developer, but I have to write to many developers
> requesting for accessibility improvements.
> And because of what I have to go through, I highlight the following 2
> lines that make all the difference between me have to beg developers
> to make their apps accessible and being ignored; and never having to
> contact them at all because nothing extra has to be done.
>
> From SWT:
> “Most of the accessibility support is built right in to the SWT
> widgets; therefore, in many cases a developer only has to use the
> widgets correctly to take advantage of the full spectrum of MSAA and
> IA2 capabilities.”
>
> From Qt (5.4):
> “*only a few changes* from your side may be required to allow even
> more users to enjoy it.”
>
>
> On 2/18/15, Marcel <lists at nightsoul.org> wrote:
>>
>>> Am 17.02.2015 um 11:23 schrieb Frederik Gladhorn
>>> <frederik.gladhorn at theqtcompany.com>:
>>>
>>> On Monday, February 16, 2015 05:51:30 PM Marcel wrote:
>>>> [Crosspost from the qt-project.org forums, didn’t receive a reply there
>>>> within a week.]
>>>>
>>>> Hello!
>>>>
>>>> I’m trying to make our application accessible with a screenreader. A
>>>> blind
>>>> colleague uses JAWS, therefore I use that for testing. Reading widgets
>>>> that
>>>> expect user input works quite well so far, but I’m having some trouble
>>>> elsewhere:
>>>>
>>>> QLabels are not read at all. JAWS has a hotkey that should “read the
>>>> whole
>>>> window” (JAWS-Key + B), but for our application that just reads the
>>>> window
>>>> title and nothing else. Everything I can focus directly via tabbing is
>>>> read
>>>> as well – which is of course not desirable with labels.
>>>>
>>>> Probably related: We have some QWizards set up. There, the QWizardPage
>>>> title
>>>> and description texts are used to convey most of the information
>>>> concerning
>>>> the wizard page’s purpose. Those texts are not read at all as well.
>>>>
>>>> I have a minimal test case application[0] that has a label (not read), a
>>>> button and a QLineEdit (accessibleName read fine for both). The button
>>>> opens a wizard that has title and description (not read) and no further
>>>> input widgets.
>>>>
>>>> Do accessible applications usually have all necessary information in
>>>> input
>>>> widget descriptions (therefore not needing labels) or am I doing
>>>> something
>>>> wrong?
>>>>
>>>> This is Qt 5.4 on Windows 8.1 with JAWS 16.
>>>
>>> QLabel should provide accessibility information (it is represented by
>>> QAccessibleDisplay in qtbase/src/widgets/accessible/simplewidgets.h).
>>>
>>> It would be interesting to know if it works with NVDA (I suspect that it
>>> does,
>>> looking at Steve's testing. The issue seems to be that we expose the
>>> information in a way that JAWS either ignores it or doesn't see it at
>>> all,
>>> so
>>> it's a bug in Qt.
>>>
>>> It would be great if you file a bug report (https://bugreports.qt.io) so
>>> we
>>> keep track of it.
>>>
>>> Does anyone know if JAWS makes use of IAccessible2 at all? Maybe that is
>>> the
>>> reason for it not working.
>>
>> I have filed the report here: https://bugreports.qt.io/browse/QTBUG-44537
>> NVDA doesn’t read that label as well when pressing NVDA+B („read whole
>> window“, results in *only* the window title being read) but announces it’s
>> accessibleName and description upon mouseover.
>>
>> Marcel
>>
>>>
>>> Cheers,
>>> Frederik
>>>
>>>>
>>>> Greetings,
>>>> Marcel
>>>>
>>>> [0] https://filetrain.de/a11ytest.zip
>>>> _______________________________________________
>>>> Accessibility mailing list
>>>> Accessibility at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/accessibility
>>
>> _______________________________________________
>> Accessibility mailing list
>> Accessibility at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/accessibility
>>
>
>
> --
> Peace
> RP
> _______________________________________________
> Accessibility mailing list
> Accessibility at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/accessibility
>


-- 
Peace
RP