Date   
NVDA 2019.2 now released

Reef Turner
 

 

Hello everyone,

NVDA 2019.2 stable has just been released. See the full post at: https://www.nvaccess.org/post/nvda-2019-2-now-available/



Thank you for all your contributions. The community is what makes NVDA what it is.

--

Reef Turner
Software Developer 

 

www.nvaccess.org

Facebook: https://www.facebook.com/NVAccess 
Twitter: @NVAccess 

 

Re: how to make a control more accessible

Luke Davis
 

Hi Travis, been a long time!

I admit I have not been following this thread closely, but an idea comes to mind.

What about just turning your program into a preprocessor, generate a temporary HTML file of the entire book, and have it opened with the default browser? You might be able to use JS to do callouts back to your code, or to other temporary files, for things you need your program to handle.

Or pick a browser, and do the whole thing as a browser plugin to begin with.

Luke

Re: how to make a control more accessible

 

Hi,
Actually, there might be a way to "reclassify" the text area as an HTML content, but doing so requires the following:]
1. A reliable way to identify this control - not object navigation emulation, but things such as window class name, control ID, and info you may fetch from accessibility API's in hopes of identifying this control.
2. A tree interceptor implementation - basically, a way to work with a tree of objects as though it is a single object, which is sort of a base for browse mode.
3. An easier way might be fooling NVDA to believe that your text area is a tree interceptor (or is associated with it). This allows NVDA to work with the text area as though it is a browse mode document. This is how support for EdgeHTML came about in 2015.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Travis Siegel
Sent: Wednesday, August 14, 2019 2:40 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] how to make a control more accessible

Yeah, but you see, that's the problem.

By itself, it doesn't work with jaws. As I said before, Jaws couldn't even see the text of the html area, until I did several things.

1. I made the html area part of the tab order.

(before that it wasn't included, because it was only a display area, and there was no need to focus the cursor there, since you couldn't do anything with it anyway).

2. I made the default focus go to this html area.
Because, without doing that, jaws couldn't find the control on the screen, I had to use the mouse to get jaws to focus on it.
3. I used the jaws-f6 (or f5, don't remember which) key to reclassify the control as an html area.
By doing that, jaws now treats the text as html text, including the capability to click on links and the whole works.
This is exactly what I was trying to make NVDA do, because when it comes down to it, it truly is html code, and that's why I was hunting for an embedded windows control to handle it for me, otherwise I'd have to write all kinds of parsing code (if for no other reason, to strip out the xml and html tags in the epub files) to have them display properly. This method saves me lots and lots of time.

Now, with that said,
Even before the changes above, NVDA did not have any problems seeing the text area, and getting to it was as simple as NVDA-left arrow when focused on the first tabbable control.

After these changes, you need only nvda-down arrow to get into the text area, then you can read the text with the normal navigation keys on the numpad.

The only issue there is that the chunks of text NVDA reads have little (if any) bearing on the actual text formatting.

That's why I'd like to reclassify the text area as an html control, so NVDA will behave properly.

The problem though is that NVDA has no facility for doing this like jaws does, so I haven't a clue how to make it happen.

As I said, it works as is, but it requires a bit more effort, and there's just no way folks are going to like that. Heck, sometimes (like if I'm eating or something) I still load up my browser to read the epub files, because I can have it read continuously instead of having to reach up and tap the numpad-9 key every few seconds.

So, if I'm not happy with tthe way it works, I know others aren't going to be happy with it either, that's the whole reason for asking here to see how this can be solved.

Using another method of displaying the file is fine, as long as that method can be integrated into my program, and not leave any stray pieces lying around.



On 8/14/2019 2:54 PM, Tyler Spivey wrote:

If the HTML control works with JAWS and lets you use browse mode, then
I would argue that it was a bug in NVDA.
Submit a simple test program with one HTMl control as an issue and see
what happens.

On 8/14/2019 11:47 AM, Travis Siegel wrote:
Yeah, but the problem is that if I use an embedded chrome browser, I
need to ship extra crap with my program, and from my experience, the
more stuff you include, the more problems people have with it,
(because they have a tendency to knowingly (or otherwise) break
things. I'd much rather use a windows embedded control even if it
isn't the best possible solution, because then there's fewer things
to break.

And, yes, it's ebook reading software. I don't know about anyone
else, but I got fed up with the inaccessible epub reading software
out there, because I couldn't find a single epub reader that did the
job simply, easily, and was 100 percent accessible. I normally just
extract the epub files myself, and read them in my browser, but I've
run across a few epub files that have what amounts to random garbage
for file names, and determining the order of reading was problematic,
so that kind of nixed the browser reading process I usually use.
Those are the main reason I set out to write this piece of software.

If nobody else uses it, that's ok with me, it solves a problem I
have, and really, that's all that's necessary. I'm just trying to
make it more user friendly, so that I can release it and allow others
to use it as well.

If I can't find a way to do that, then I'll leave it as is, but I
just know I'm going to get complaints because it doesn't read
automatically, or because it doesn't handle broken epub files, or
because it doesn't read outloud, or any number of other issues I
haven't even thought of yet.

Folks really tend to blow up if it works well for one screen reader,
but not for another one, so that's why the questions here. I have no
trouble making it work perfectly with jaws, and I'd really like to
have that same transparency with NVDA, since that's my screen reader
of choice, and it's kind of sad that I'd release a program that works
better on a screen reader I don't even use.


On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next
chapter", it sounds like you're creating some sort of reading
software. If it's for eBooks, that really strengthens the case for
a better browser engine. There's no reason an embedded Chrome
browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file.
Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014,
so it's a relatively old dll to be sure. But, that means this code
will work on just about any version of windows, which was my
primary intent when I started the project. Admittedly, I didn't
have a clue how to do what I wanted (I.E. embed an html control
into my program) when I started, but via some heavy use of google,
and a bit of searching on my favorite programming sites, I found
this little gem that was only a couple functions, a couple api
calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control
is an html area, it behaves properly, (which it most certainly did
not do before doing so). In fact, before I told jaws it was an
html control, jaws couldn't even find the text on the screen. To
fix that problem, I had to add the html area to the tab order, then
tell jaws it was anhtml control, after that, jaws works like a
dream, pressing the button (or hot key) to go to the next chapter
starts jaws reading the text automatically just as soon as it comes
up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing
the html control is on the screen, it finds it just fine, and I can
even read it, but again, I have to use the numpad keys to work my
way through the text. Interestingly enough, NVDA doesn't seem to
know about the various headers, links, and other html elements in
the text, but jaws not only sees them, but alows me to click on
them as if it were an actual browser. I'm not real happy with that
result, since it means NVDA is being shown up at something it
initially has a much better handle on, so if I could tell NVDA this
is an html area, and allow it to behave accordingly, I'm fairly
certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample.
However, straight off the bat, I'd recommend using a more
up-to-date rendering engine for your web view (Chromium would be
ideal for instance via CEF).

What environment is creating the web view? Is it a standard Win32
app? WPF? WinForms? UWP? Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of
it's main screen. NVDA reads the text well enough, but it
doesn't read it well, in that it breaks lines at unexpected
places, and it doesn't show embedded links. The links isn't
really a problem, since I'm not really concerned with links
pointing elsewhere anyhow, so that's only a minor issue, but I
would like to know how to get NVDA to treat this text area as
html text, so it will pay attention to things like headers, and
handle the reading a bit better, since now it's reading the text
in the window in fragments, and most of the time, those fragments
aren't making sense.

Admittedly, I'm not sure how much control I have over the
presentation of the text, since it's an imported one, (it calls a
windows dll/api to render the text), but when I look at the text
line by line, it seems odd to me where NVDA is choosing to put
breaks, as well as the fact that the read to end function in NVDA
doesn't work. This at least is one thing I'd really like to fix,
since reading is the primary purpose of the app. I'll include
the nvda-F1 text below for the control, perhaps someone here can
help me figure out what I need to do to make it work better,
whether it be via NVDA plugins, or just adding attributes to the
window. There's only so much I can do programatically, since it's
an api/dll call, but I'm certainly open to suggestions. It works
as is, but reading the text requires the nvda cursor, not the
system one, and I know some folks aren't going to like that, so
again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object:
<NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMS
HTMLIAccessible
object at 0x05256770>
Python class mro: (<class
'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMS
HTMLIAccessible'>,
<class
'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>,
<class 'editableText.EditableTextWithoutAutoSelectDetection'>,
<class 'NVDAObjects.behaviors.EditableText'>, <class
'editableText.EditableText'>, <class
'NVDAObjects.IAccessible.MSHTML.Body'>, <class
'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class
'NVDAObjects.IAccessible.IAccessible'>, <class
'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>,
<class 'documentBase.TextContainerObject'>, <class
'baseObject.ScriptableObject'>, <class
'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID
1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at
5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670,
objectID=None, childID=0 IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE IAccessible accState:
STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64) IAccessible
accDescription: exception: (-2147467263, 'Not implemented',
(None, None, None, 0, None)) IAccessible accValue:
u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill
DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False MSHTML nodeName:
u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object,
because it's most certainly not editable <frown>

The rest seems to be correct though.















Re: how to make a control more accessible

Travis Siegel
 

Yeah, but you see, that's the problem.

By itself, it doesn't work with jaws.  As I said before, Jaws couldn't even see the text of the html area, until I did several things.

1. I made the html area part of the tab order.

(before that it wasn't included, because it was only a display area, and there was no need to focus the cursor there, since you couldn't do anything with it anyway).

2. I made the default focus go to this html area.
Because, without doing that, jaws couldn't find the control on the screen, I had to use the mouse to get jaws to focus on it.
3. I used the jaws-f6 (or f5, don't remember which) key to reclassify the control as an html area.
By doing that, jaws now treats the text as html text, including the capability to click on links and the whole works.
This is exactly what I was trying to make NVDA do, because when it comes down to it, it truly is html code, and that's why I was hunting for an embedded windows control to handle it for me, otherwise I'd have to write all kinds of parsing code (if for no other reason, to strip out the xml and html tags in the epub files) to have them display properly.  This method saves me lots and lots of time.

Now, with that said,
Even before the changes above, NVDA did not have any problems seeing the text area, and getting to it was as simple as NVDA-left arrow when focused on the first tabbable control.

After these changes, you need only nvda-down arrow to get into the text area, then you can read the text with the normal navigation keys on the numpad.

The only issue there is that the chunks of text NVDA reads have little (if any) bearing on the actual text formatting.

That's why I'd like to reclassify the text area as an html control, so NVDA will behave properly.

The problem though is that NVDA has no facility for doing this like jaws does, so I haven't a clue how to make it happen.

As I said, it works as is, but it requires a bit more effort, and there's just no way folks are going to like that.  Heck, sometimes (like if I'm eating or something) I still load up my browser to read the epub files, because I can have it read continuously instead of having to reach up and tap the numpad-9 key every few seconds.

So, if I'm not happy with tthe way it works, I know others aren't going to be happy with it either, that's the whole reason for asking here to see how this can be solved.

Using another method of displaying the file is fine, as long as that method can be integrated into my program, and not leave any stray pieces lying around.

On 8/14/2019 2:54 PM, Tyler Spivey wrote:

If the HTML control works with JAWS and lets you use browse mode, then I would argue that it was a bug in NVDA.
Submit a simple test program with one HTMl control as an issue and see what happens.

On 8/14/2019 11:47 AM, Travis Siegel wrote:
Yeah, but the problem is that if I use an embedded chrome browser, I need to ship extra crap with my program, and from my experience, the more stuff you include, the more problems people have with it, (because they have a tendency to knowingly (or otherwise) break things.  I'd much rather use a windows embedded control even if it isn't the best possible solution, because then there's fewer things to break.

And, yes, it's ebook reading software.  I don't know about anyone else, but I got fed up with the inaccessible epub reading software out there, because I couldn't find a single epub reader that did the job simply, easily, and was 100 percent accessible.  I normally just extract the epub files myself, and read them in my browser, but I've run across a few epub files that have what amounts to random garbage for file names, and determining the order of reading was problematic, so that kind of nixed the browser reading process I usually use.  Those are the main reason I set out to write this piece of software.

If nobody else uses it, that's ok with me, it solves a problem I have, and really, that's all that's necessary.  I'm just trying to make it more user friendly, so that I can release it and allow others to use it as well.

If I can't find a way to do that, then I'll leave it as is, but I just know I'm going to get complaints because it doesn't read automatically, or because it doesn't handle broken epub files, or because it doesn't read outloud, or any number of other issues I haven't even thought of yet.

Folks really tend to blow up if it works well for one screen reader, but not for another one, so that's why the questions here.  I have no trouble making it work perfectly with jaws, and I'd really like to have that same transparency with NVDA, since that's my screen reader of choice, and it's kind of sad that I'd release a program that works better on a screen reader I don't even use.


On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software.  If it's for eBooks, that really strengthens the case for a better browser engine. There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file. Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.














Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

It seems to have sorted it out after the alpha update. I guess having both python 2 and 3 versions of nvda on this windows 7 machine might be an issue from time to time. Also still no auto update on alpha snaps, it says its checking but never does till I force it from the help menu.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 8:21 PM
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi,
The traceback? No, that one (again) has nothing to do with Python 3 alpha
and inability to update them via Add-on updater at this time. Although I
might be able to resolve issues with add-ons using update channel manifest
key in odd ways from the server side, I prefer to let authors handle this
themselves. As I wrote before, I'll provide a way to let outdated add-ons
with odd update channel behavior receive updates via Add-on Updater in
upcoming version 19.08.1 and 19.09.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Wednesday, August 14, 2019 12:12 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3
alpha builds of Resource Monitor and StationPlaylist are now available

OK one query. I've updated nothing on the alpha branch since yesterday, but
booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda
extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead IO -
inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists icon 1 of 2'] IO - speech.speak
(20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists'] IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject:
[nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of
Resource Monitor and StationPlaylist are now available; Received: 14/08/2019
18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha
builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of
some of my add-ons (ones with Python 3 strict branch or requiring NVDA
2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now
that it did, I'm releasing Python 3 alpha versions of the following
add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-
py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-
py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on
Updater doesn't know how to check for updates for Python 3 alpha
builds, and that is intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on
that warrants testing with NVDA 2019.3 alpha. Those on development
snapshots (regular ones, that is) will not see Python 3 version of SPL
add-on until shortly after 2019.3 RC is released; a limited field
testing will take place during 2019.3 beta cycle. Due to pickle
protocol changes, after installing today's alpha snapshot, there is no
going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of
Resource Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph








Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

I have now downloaded the latest alpha and that error has not reappeared.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 8:19 PM
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Erm if you are running both versions of resource monitor together now, why would you change that as leaving the python 2 parts would presumably mean you only need one copy of that add on if you have old and new versions of nvda in use. I know a lot of people who keep older versions around as well.
Is this not making more work for everyone and yourself?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph




Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

 

Hi,
The traceback? No, that one (again) has nothing to do with Python 3 alpha
and inability to update them via Add-on updater at this time. Although I
might be able to resolve issues with add-ons using update channel manifest
key in odd ways from the server side, I prefer to let authors handle this
themselves. As I wrote before, I'll provide a way to let outdated add-ons
with odd update channel behavior receive updates via Add-on Updater in
upcoming version 19.08.1 and 19.09.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail
list account via Groups.Io
Sent: Wednesday, August 14, 2019 12:12 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3
alpha builds of Resource Monitor and StationPlaylist are now available

OK one query. I've updated nothing on the alpha branch since yesterday, but
booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar'] DEBUGWARNING -
characterProcessing._getSpeechSymbolsForLocale
(20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda
extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandler
Ex.py",
line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead IO -
inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists icon 1 of 2'] IO - speech.speak
(20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express
- Brians lists account BGlists'] IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject:
[nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of
Resource Monitor and StationPlaylist are now available; Received: 14/08/2019
18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha
builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of
some of my add-ons (ones with Python 3 strict branch or requiring NVDA
2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now
that it did, I'm releasing Python 3 alpha versions of the following
add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-
py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-
py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on
Updater doesn't know how to check for updates for Python 3 alpha
builds, and that is intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on
that warrants testing with NVDA 2019.3 alpha. Those on development
snapshots (regular ones, that is) will not see Python 3 version of SPL
add-on until shortly after 2019.3 RC is released; a limited field
testing will take place during 2019.3 beta cycle. Due to pickle
protocol changes, after installing today's alpha snapshot, there is no
going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of
Resource Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph




Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

Erm if you are running both versions of resource monitor together now, why would you change that as leaving the python 2 parts would presumably mean you only need one copy of that add on if you have old and new versions of nvda in use. I know a lot of people who keep older versions around as well.
Is this not making more work for everyone and yourself?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph



Re: Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

Brian's Mail list account
 

OK one query. I've updated nothing on the alpha branch since yesterday, but booting up alpha today gives...
initializing updateCheck
INFO - core.main (20:07:28.700):
NVDA initialized
DEBUG - core.main (20:07:28.701):
entering wx application main loop
INFO - updateCheck.AutoUpdateChecker._started (20:07:28.712):
Performing automatic update check
IO - speech.speak (20:07:28.739):
Speaking [LangChangeCommand ('en_GB'), 'Taskbar']
DEBUGWARNING - characterProcessing._getSpeechSymbolsForLocale (20:07:28.740):
No CLDR data for locale en_GB
ERROR - stderr (20:07:29.565):
Exception in thread Thread-23:
Traceback (most recent call last):
File "threading.pyc", line 926, in _bootstrap_inner
File "threading.pyc", line 870, in run
File "C:\nvda extra\userConfig\addons\addonUpdater\globalPlugins\addonUpdater\addonHandlerEx.py", line 134, in fetchAddonInfo
addonUrl = results[addonKey]
KeyError: 'tbx-stable'
DEBUG - windowUtils.getWindowScalingFactor (20:07:30.091):
GetDpiForWindow failed, using GetDeviceCaps instead
IO - inputCore.InputManager.executeGesture (20:07:33.454):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:33.998):
Input: kb(desktop):upArrow
IO - inputCore.InputManager.executeGesture (20:07:36.174):
Input: kb(desktop):downArrow
IO - inputCore.InputManager.executeGesture (20:07:37.054):
Input: kb(desktop):alt+tab
IO - speech.speak (20:07:37.117):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express - Brians lists account BGlists icon 1 of 2']
IO - speech.speak (20:07:37.742):
Speaking [LangChangeCommand ('en_GB'), '2nvda develop list - Outlook Express - Brians lists account BGlists']
IO - speech.speak (20:07:37.842):
Speaking [LangChangeCommand ('en_GB'), 'Outlook Express Message List list']
IO - speech.speak (20:07:37.940):
Speaking [LangChangeCommand ('en_GB'), "From: Joseph Lee; Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available; Received: 14/08/2019 18:23 1392 of

Is this due to the way you are stopping Python 3 add ons in add on updater?


Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 6:23 PM
Subject: [nvda-devel] Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available


Hi all,



A few days ago I wrote that I'll release Python 3 alpha versions of some of
my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3
technologies) shortly after NVDA 2019.2 sees the light of day. Now that it
did, I'm releasing Python 3 alpha versions of the following add-ons:



* Resource Monitor:
http://www.josephsl.net/files/nvdaaddons/py3/resourceMonitor-20190814-py3.nv
da-addon
* StationPlaylist:
http://www.josephsl.net/files/nvdaaddons/py3/stationPlaylist-20190814-py3.nv
da-addon





IMPORTANT NOTES:

1. These add-ons REQUIRE NVDA 2019.3 alpha.
2. Update check for these add-ons will not be possible - Add-on Updater
doesn't know how to check for updates for Python 3 alpha builds, and that is
intentional.
3. After installing these add-ons, there is no going back. For this
reason, please use another copy of NVDA for testing these add-ons.
4. For StationPlaylist users: the Python 3 alpha builds of this add-on
will be released only if significant changes were made to SPL add-on that
warrants testing with NVDA 2019.3 alpha. Those on development snapshots
(regular ones, that is) will not see Python 3 version of SPL add-on until
shortly after 2019.3 RC is released; a limited field testing will take place
during 2019.3 beta cycle. Due to pickle protocol changes, after installing
today's alpha snapshot, there is no going back.
5. For Resource Monitor users: you'll notice smaller download size due
to removal of Python 2 version of psutil. Python 3 alpha version of Resource
Monitor will bundle Python 3 version of psutil.
6. There will be more add-ons joining the Python 3 alpha testing
program, either because they will be optimized for Python 3 (such as
SystrayList), supports newer versions of NVDA (such as Windows 10 App
Essentials), or a combination of these.



Any feedback on my add-ons participating in Python 3 alpha testing are
welcome.

Cheers,

Joseph



Re: how to make a control more accessible

Tyler Spivey
 

If the HTML control works with JAWS and lets you use browse mode, then I would argue that it was a bug in NVDA.
Submit a simple test program with one HTMl control as an issue and see what happens.

On 8/14/2019 11:47 AM, Travis Siegel wrote:
Yeah, but the problem is that if I use an embedded chrome browser, I need to ship extra crap with my program, and from my experience, the more stuff you include, the more problems people have with it, (because they have a tendency to knowingly (or otherwise) break things.  I'd much rather use a windows embedded control even if it isn't the best possible solution, because then there's fewer things to break.
And, yes, it's ebook reading software.  I don't know about anyone else, but I got fed up with the inaccessible epub reading software out there, because I couldn't find a single epub reader that did the job simply, easily, and was 100 percent accessible.  I normally just extract the epub files myself, and read them in my browser, but I've run across a few epub files that have what amounts to random garbage for file names, and determining the order of reading was problematic, so that kind of nixed the browser reading process I usually use.  Those are the main reason I set out to write this piece of software.
If nobody else uses it, that's ok with me, it solves a problem I have, and really, that's all that's necessary.  I'm just trying to make it more user friendly, so that I can release it and allow others to use it as well.
If I can't find a way to do that, then I'll leave it as is, but I just know I'm going to get complaints because it doesn't read automatically, or because it doesn't handle broken epub files, or because it doesn't read outloud, or any number of other issues I haven't even thought of yet.
Folks really tend to blow up if it works well for one screen reader, but not for another one, so that's why the questions here.  I have no trouble making it work perfectly with jaws, and I'd really like to have that same transparency with NVDA, since that's my screen reader of choice, and it's kind of sad that I'd release a program that works better on a screen reader I don't even use.
On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software.  If it's for eBooks, that really strengthens the case for a better browser engine.  There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file. Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.










Re: how to make a control more accessible

Travis Siegel
 

Yeah, but the problem is that if I use an embedded chrome browser, I need to ship extra crap with my program, and from my experience, the more stuff you include, the more problems people have with it, (because they have a tendency to knowingly (or otherwise) break things.  I'd much rather use a windows embedded control even if it isn't the best possible solution, because then there's fewer things to break.

And, yes, it's ebook reading software.  I don't know about anyone else, but I got fed up with the inaccessible epub reading software out there, because I couldn't find a single epub reader that did the job simply, easily, and was 100 percent accessible.  I normally just extract the epub files myself, and read them in my browser, but I've run across a few epub files that have what amounts to random garbage for file names, and determining the order of reading was problematic, so that kind of nixed the browser reading process I usually use.  Those are the main reason I set out to write this piece of software.

If nobody else uses it, that's ok with me, it solves a problem I have, and really, that's all that's necessary.  I'm just trying to make it more user friendly, so that I can release it and allow others to use it as well.

If I can't find a way to do that, then I'll leave it as is, but I just know I'm going to get complaints because it doesn't read automatically, or because it doesn't handle broken epub files, or because it doesn't read outloud, or any number of other issues I haven't even thought of yet.

Folks really tend to blow up if it works well for one screen reader, but not for another one, so that's why the questions here.  I have no trouble making it work perfectly with jaws, and I'd really like to have that same transparency with NVDA, since that's my screen reader of choice, and it's kind of sad that I'd release a program that works better on a screen reader I don't even use.

On 8/14/2019 3:55 AM, James Scholes wrote:

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software.  If it's for eBooks, that really strengthens the case for a better browser engine.  There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.









Joseph Lee's add-ons and NVDA 2019.3: Python 3 alpha builds of Resource Monitor and StationPlaylist are now available

 

Hi all,

 

A few days ago I wrote that I’ll release Python 3 alpha versions of some of my add-ons (ones with Python 3 strict branch or requiring NVDA 2019.3 technologies) shortly after NVDA 2019.2 sees the light of day. Now that it did, I’m releasing Python 3 alpha versions of the following add-ons:

 

 

 

IMPORTANT NOTES:

  1. These add-ons REQUIRE NVDA 2019.3 alpha.
  2. Update check for these add-ons will not be possible – Add-on Updater doesn’t know how to check for updates for Python 3 alpha builds, and that is intentional.
  3. After installing these add-ons, there is no going back. For this reason, please use another copy of NVDA for testing these add-ons.
  4. For StationPlaylist users: the Python 3 alpha builds of this add-on will be released only if significant changes were made to SPL add-on that warrants testing with NVDA 2019.3 alpha. Those on development snapshots (regular ones, that is) will not see Python 3 version of SPL add-on until shortly after 2019.3 RC is released; a limited field testing will take place during 2019.3 beta cycle. Due to pickle protocol changes, after installing today’s alpha snapshot, there is no going back.
  5. For Resource Monitor users: you’ll notice smaller download size due to removal of Python 2 version of psutil. Python 3 alpha version of Resource Monitor will bundle Python 3 version of psutil.
  6. There will be more add-ons joining the Python 3 alpha testing program, either because they will be optimized for Python 3 (such as SystrayList), supports newer versions of NVDA (such as Windows 10 App Essentials), or a combination of these.

 

Any feedback on my add-ons participating in Python 3 alpha testing are welcome.

Cheers,

Joseph

Re: how to make a control more accessible

Brian's Mail list account
 

It seems the implementation is not triggering the creation of the virtual buffer here, which is why its not working.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Travis Siegel" <tsiegel@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, August 14, 2019 12:34 AM
Subject: Re: [nvda-devel] how to make a control more accessible


It's actually calling routines in the ATL.DLL windows library file. Two
routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so
it's a relatively old dll to be sure. But, that means this code will
work on just about any version of windows, which was my primary intent
when I started the project. Admittedly, I didn't have a clue how to do
what I wanted (I.E. embed an html control into my program) when I
started, but via some heavy use of google, and a bit of searching on my
favorite programming sites, I found this little gem that was only a
couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an
html area, it behaves properly, (which it most certainly did not do
before doing so). In fact, before I told jaws it was an html control,
jaws couldn't even find the text on the screen. To fix that problem, I
had to add the html area to the tab order, then tell jaws it was anhtml
control, after that, jaws works like a dream, pressing the button (or
hot key) to go to the next chapter starts jaws reading the text
automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the
html control is on the screen, it finds it just fine, and I can even
read it, but again, I have to use the numpad keys to work my way through
the text. Interestingly enough, NVDA doesn't seem to know about the
various headers, links, and other html elements in the text, but jaws
not only sees them, but alows me to click on them as if it were an
actual browser. I'm not real happy with that result, since it means
NVDA is being shown up at something it initially has a much better
handle on, so if I could tell NVDA this is an html area, and allow it to
behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.


On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view? Is it a standard Win32 app? WPF? WinForms? UWP? Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen. NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app. I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions. It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.






Re: how to make a control more accessible

James Scholes
 

I don't want to stress overly on this, but when you say "next chapter", it sounds like you're creating some sort of reading software. If it's for eBooks, that really strengthens the case for a better browser engine. There's no reason an embedded Chrome browser can't work across multiple versions of Windows.

Regards,

James Scholes

On 14/08/2019 at 12:34 am, Travis Siegel wrote:
It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.
The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.
Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.
I was hoping I could do something similar for NVDA.
Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.
I just don't know how to do that.
On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work. This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.






Re: how to make a control more accessible

Travis Siegel
 

It's actually calling routines in the ATL.DLL windows library file.  Two routines from that dll initialize and process the html view.

The atl.dll file on my windows 8.1 system has a file stamp of 2014, so it's a relatively old dll to be sure.  But, that means this code will work on just about any version of windows, which was my primary intent when I started the project.  Admittedly, I didn't have a clue how to do what I wanted (I.E. embed an html control into my program) when I started, but via some heavy use of google, and a bit of searching on my favorite programming sites, I found this little gem that was only a couple functions, a couple api calls, and poof, exactly what I wanted.

Interestingly enough, under jaws, if I tell jaws that the control is an html area, it behaves properly, (which it most certainly did not do before doing so).  In fact, before I told jaws it was an html control, jaws couldn't even find the text on the screen.  To fix that problem, I had to add the html area to the tab order, then tell jaws it was anhtml control, after that, jaws works like a dream, pressing the button (or hot key) to go to the next chapter starts jaws reading the text automatically just as soon as it comes up on the screen.

I was hoping I could do something similar for NVDA.

Especially, since NVDA doesn't suffer from the issue of not knowing the html control is on the screen, it finds it just fine, and I can even read it, but again, I have to use the numpad keys to work my way through the text.  Interestingly enough, NVDA doesn't seem to know about the various headers, links, and other html elements in the text, but jaws not only sees them, but alows me to click on them as if it were an actual browser.  I'm not real happy with that result, since it means NVDA is being shown up at something it initially has a much better handle on, so if I could tell NVDA this is an html area, and allow it to behave accordingly, I'm fairly certain all would work like a treat.

I just don't know how to do that.

On 8/13/2019 5:50 PM, James Scholes wrote:

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view?  Is it a standard Win32 app? WPF?  WinForms?  UWP?  Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links. The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.





Re: how to make a control more accessible

James Scholes
 

It may be helpful in this instance to have a runnable sample. However, straight off the bat, I'd recommend using a more up-to-date rendering engine for your web view (Chromium would be ideal for instance via CEF).

What environment is creating the web view? Is it a standard Win32 app? WPF? WinForms? UWP? Something else?

Regards,

James Scholes

On 13/08/2019 at 9:21 pm, Travis Siegel wrote:
I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links.  The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.
Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.
** cut here **
Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**
I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>
The rest seems to be correct though.

how to make a control more accessible

Travis Siegel
 

I have a program I'm working on that has an html view as part of it's main screen.  NVDA reads the text well enough, but it doesn't read it well, in that it breaks lines at unexpected places, and it doesn't show embedded links.  The links isn't really a problem, since I'm not really concerned with links pointing elsewhere anyhow, so that's only a minor issue, but I would like to know how to get NVDA to treat this text area as html text, so it will pay attention to things like headers, and handle the reading a bit better, since now it's reading the text in the window in fragments, and most of the time, those fragments aren't making sense.

Admittedly, I'm not sure how much control I have over the presentation of the text, since it's an imported one, (it calls a windows dll/api to render the text), but when I look at the text line by line, it seems odd to me where NVDA is choosing to put breaks, as well as the fact that the read to end function in NVDA doesn't work.  This at least is one thing I'd really like to fix, since reading is the primary purpose of the app.  I'll include the nvda-F1 text below for the control, perhaps someone here can help me figure out what I need to do to make it work better, whether it be via NVDA plugins, or just adding attributes to the window. There's only so much I can do programatically, since it's an api/dll call, but I'm certainly open to suggestions.  It works as is, but reading the text requires the nvda cursor, not the system one, and I know some folks aren't going to like that, so again, any suggestions would be appreciated.

** cut here **

Developer info for navigator object:
name: u'Copyright'
role: ROLE_DOCUMENT
states: STATE_READONLY
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible object at 0x05256770>
Python class mro: (<class 'NVDAObjects.Dynamic_EditableTextWithoutAutoSelectDetectionBodyMSHTMLIAccessible'>, <class 'NVDAObjects.behaviors.EditableTextWithoutAutoSelectDetection'>, <class 'editableText.EditableTextWithoutAutoSelectDetection'>, <class 'NVDAObjects.behaviors.EditableText'>, <class 'editableText.EditableText'>, <class 'NVDAObjects.IAccessible.MSHTML.Body'>, <class 'NVDAObjects.IAccessible.MSHTML.MSHTML'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: RectLTWH(left=412, top=186, width=759, height=628)
value: ''
appModule: <'appModuleHandler' (appName u'reader', process ID 1084) at address 52567b0>
appModule.productName: exception: No version information
appModule.productVersion: exception: No version information
TextInfo: <class 'NVDAObjects.IAccessible.MSHTML.MSHTMLTextInfo'>
windowHandle: 2556670
windowClassName: u'Internet Explorer_Server'
windowControlID: 0
windowStyle: 1442840576
windowThreadID: 6488
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x9039038 at 5085170>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=2556670, objectID=None, childID=0
IAccessible accName: u'Copyright'
IAccessible accRole: ROLE_SYSTEM_PANE
IAccessible accState: STATE_SYSTEM_READONLY, STATE_SYSTEM_VALID (64)
IAccessible accDescription: exception: (-2147467263, 'Not implemented', (None, None, None, 0, None))
IAccessible accValue: u'file://C:\\books\\storybundle\\Adventure\\Singularity - Bill DeSmedt\\OEBPS\\copyright.xhtml'
MSHTML node has ancestor IAccessible: False
MSHTML nodeName: u'body'
** cut here**

I'm actually not sure why it's claiming it's an editable object, because it's most certainly not editable <frown>

The rest seems to be correct though.

Re: Control Usage Assistant: August 13th development snapshot

 

Hi,

For anyone using Add-on Updater: Add-on Update method won’t work because Control Usage Assistant isn’t registered with this add-on. I’ll correct this issue as part of Add-on Updater 19.08.1/19.09. Sorry about that.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Monday, August 12, 2019 8:24 PM
To: nvda-devel@groups.io
Subject: [nvda-devel] Control Usage Assistant: August 13th development snapshot

 

Hi everyone,

 

Control Usage Assistant August 13th development snapshot is now available. As promised, this one introduces a completely new way of obtaining help, along with a new help message interface.

 

For anyone wishing to take a look at add-on source code: I’d like to inform you that the official source code repo for this add-on has changed. Going forward, all add-on development will take place on GitHub, not Bitbucket. The new (and now official) repo can be found at:

https://github.com/josephsl/controlusageassistant

 

What’s new and different from version 2.5/nightlight: in addition to the new repo, we have:

 

Help messages database, completely redesigned: in version 2.5 and earlier, Control Usage Assistant used object role constants from control types module to retrieve help messages from a central database (really a dictionary), with some scenarios involving an offset (browse mode and messages for controls from some apps, for instance). While it did allow help messages to be defined for well-known controls, it did not leave room for extending the database by adding messages for controls only seen in some apps.

 

The new Control Usage Assistant add-on will now use multiple help message databases to store help messages. There is the default role-based help messages dictionary as before, along with dictionaries to store help messages based on class names for various objects (such as NVDAObjects.behaviors.EditableTextWithSuggestions), including those found in app modules (such as PowerPoint slide shows) included in NVDA. The just released snapshot collects messages found in version 2.5 with one notable omission: help message for read-only edit fields, which I’ll do something about soon.

 

A different procedure for fetching help messages from everywhere: coupled with help message database redesign, a new way to fetch help messages is introduced. Version 2.5 and earlier just looked at object roles and one or two constraints such as whether browse mode is active or dealing with one or two controls from specific apps. Starting with the just released snapshot, NVDA will first look at help messages for objects themselves, followed by one or more constraints such as browse mode, before resorting to role-based help messages.

 

The biggest change from the old releases is how NVDA can figure out help messages for objects. This is done by traversing an object’s method resolution order (MRO), a record of class hierarchy relationships used for attribute lookup and other tasks. For example, for an overlay class defined in an app module which is in turn based on an API class, the class hierarchy (or MRO) for an overlay class starts with the app module one, followed by one or more API level classes, and then proceeding to base NVDA object and its constituent objects such as scriptable object.

 

For each MRO entry, NVDA will look at a string representation of the class name, which is then used as a key to look up object-specific help message. For example, if one is dealing with a custom table object from an app module that is in turn a fake table row object, NVDA can potentially look up help messages for at least two objects: the overlay class found in the app module, and the help message for the fake table row behavior. Only after messages from objects are exhausted will NVDA retrieve help messages based on an object’s role provided that there is one, and if there is no help message whatsoever, NVDA will say, “no help for this control”.

 

During each help message retrieval pass, potential help messages are gathered into a list, including a message about no help for a control. This list is important because it powers the next feature.

 

Same command, different help message interface: the command for getting help on a focused control (NVDA+H) remains the same. But this is where the similarity ends. In version 2.5, NVDA would flash the help message in speech and/or braille. Starting with the just released snapshot, you can (finally) review help messages in a browse mode window. Not only this resolves a problem where you had to press the help command again if you missed the help message, you can now review help messages at your leisure and makes the experience closer to other screen readers.

 

Recall that potential help messages are gathered into a list. The above interface change is why: just before NVDA displays a help message (or several of them) in a browse mode window, entries in that list are transformed into a string. In addition, the help message screen ends with the phrase, “press Escape to close this help screen”. Sounds familiar? This is the exact message borrowed from PAC Mate’s help screen (if you know what I mean), and in some way, is very close to how help screen works for BrailleNote Touch/Touch Plus users (I now am a user of a BrailleNote Touch Plus).

 

How to obtain the development snapshot: there are two ways:

 

  1. Go to community add-ons website (addons.nvda-project.org), select Control Usage Assistant, and select development version link.
  2. If using Add-on Updater, go to NvDA Settings/Add-on Updater, and check “Control Usage Assistant” under “prefer development releases” list and click OK. Then check for add-on updates.

 

How to help: you can help out by sending feedback to me (either on various NVDA lists or privately), or if you are willing, filing issues and pull requests. In particular, I will need help with the following tasks:

 

  1. Code review (for add-ons community): I’ll be sending an official basic review request to add-ons community, because this add-on wasn’t reviewed in a long time.
  2. Adding help messages for specific controls: to do this, after locating the control in question, send me the developer info along with a short help message. If you wish to do so yourself, locate the class MRO for the object, add it to the objects help messages database along with a short help message, and package it as a pull request. If you are adding help messages for roles, be sure to record the role and the help message.
  3. If you are really adventurous and wish to help out with NVDA Core pull request: relevant details can be found at https://github.com/nvaccess/nvda/issues/2699. If you wish to track the work being done, check out josephsl/i2699contextSensitiveHelp branch.

 

Enjoy.

Cheers,

Joseph

Control Usage Assistant: August 13th development snapshot

 

Hi everyone,

 

Control Usage Assistant August 13th development snapshot is now available. As promised, this one introduces a completely new way of obtaining help, along with a new help message interface.

 

For anyone wishing to take a look at add-on source code: I’d like to inform you that the official source code repo for this add-on has changed. Going forward, all add-on development will take place on GitHub, not Bitbucket. The new (and now official) repo can be found at:

https://github.com/josephsl/controlusageassistant

 

What’s new and different from version 2.5/nightlight: in addition to the new repo, we have:

 

Help messages database, completely redesigned: in version 2.5 and earlier, Control Usage Assistant used object role constants from control types module to retrieve help messages from a central database (really a dictionary), with some scenarios involving an offset (browse mode and messages for controls from some apps, for instance). While it did allow help messages to be defined for well-known controls, it did not leave room for extending the database by adding messages for controls only seen in some apps.

 

The new Control Usage Assistant add-on will now use multiple help message databases to store help messages. There is the default role-based help messages dictionary as before, along with dictionaries to store help messages based on class names for various objects (such as NVDAObjects.behaviors.EditableTextWithSuggestions), including those found in app modules (such as PowerPoint slide shows) included in NVDA. The just released snapshot collects messages found in version 2.5 with one notable omission: help message for read-only edit fields, which I’ll do something about soon.

 

A different procedure for fetching help messages from everywhere: coupled with help message database redesign, a new way to fetch help messages is introduced. Version 2.5 and earlier just looked at object roles and one or two constraints such as whether browse mode is active or dealing with one or two controls from specific apps. Starting with the just released snapshot, NVDA will first look at help messages for objects themselves, followed by one or more constraints such as browse mode, before resorting to role-based help messages.

 

The biggest change from the old releases is how NVDA can figure out help messages for objects. This is done by traversing an object’s method resolution order (MRO), a record of class hierarchy relationships used for attribute lookup and other tasks. For example, for an overlay class defined in an app module which is in turn based on an API class, the class hierarchy (or MRO) for an overlay class starts with the app module one, followed by one or more API level classes, and then proceeding to base NVDA object and its constituent objects such as scriptable object.

 

For each MRO entry, NVDA will look at a string representation of the class name, which is then used as a key to look up object-specific help message. For example, if one is dealing with a custom table object from an app module that is in turn a fake table row object, NVDA can potentially look up help messages for at least two objects: the overlay class found in the app module, and the help message for the fake table row behavior. Only after messages from objects are exhausted will NVDA retrieve help messages based on an object’s role provided that there is one, and if there is no help message whatsoever, NVDA will say, “no help for this control”.

 

During each help message retrieval pass, potential help messages are gathered into a list, including a message about no help for a control. This list is important because it powers the next feature.

 

Same command, different help message interface: the command for getting help on a focused control (NVDA+H) remains the same. But this is where the similarity ends. In version 2.5, NVDA would flash the help message in speech and/or braille. Starting with the just released snapshot, you can (finally) review help messages in a browse mode window. Not only this resolves a problem where you had to press the help command again if you missed the help message, you can now review help messages at your leisure and makes the experience closer to other screen readers.

 

Recall that potential help messages are gathered into a list. The above interface change is why: just before NVDA displays a help message (or several of them) in a browse mode window, entries in that list are transformed into a string. In addition, the help message screen ends with the phrase, “press Escape to close this help screen”. Sounds familiar? This is the exact message borrowed from PAC Mate’s help screen (if you know what I mean), and in some way, is very close to how help screen works for BrailleNote Touch/Touch Plus users (I now am a user of a BrailleNote Touch Plus).

 

How to obtain the development snapshot: there are two ways:

 

  1. Go to community add-ons website (addons.nvda-project.org), select Control Usage Assistant, and select development version link.
  2. If using Add-on Updater, go to NvDA Settings/Add-on Updater, and check “Control Usage Assistant” under “prefer development releases” list and click OK. Then check for add-on updates.

 

How to help: you can help out by sending feedback to me (either on various NVDA lists or privately), or if you are willing, filing issues and pull requests. In particular, I will need help with the following tasks:

 

  1. Code review (for add-ons community): I’ll be sending an official basic review request to add-ons community, because this add-on wasn’t reviewed in a long time.
  2. Adding help messages for specific controls: to do this, after locating the control in question, send me the developer info along with a short help message. If you wish to do so yourself, locate the class MRO for the object, add it to the objects help messages database along with a short help message, and package it as a pull request. If you are adding help messages for roles, be sure to record the role and the help message.
  3. If you are really adventurous and wish to help out with NVDA Core pull request: relevant details can be found at https://github.com/nvaccess/nvda/issues/2699. If you wish to track the work being done, check out josephsl/i2699contextSensitiveHelp branch.

 

Enjoy.

Cheers,

Joseph

Re: I suspect auto update is broken on alpha snaps

derek riemer
 

Seems like I haven't gotten any updates in a while.

On Tue, Aug 6, 2019 at 8:13 AM Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io> wrote:
I have to force it to look every time, whereas other branches seem to tell
me almost straight away after loading in the morning.

Could this be the case or is my experience  unusual?

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users






--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com