Screen reader accessibility for blind users?

I’m wondering, Would there be any interest from the manager developers to making the program more screen reader friendly for blind users?
As it is now the program works reasonably well, better than most accounting systems in this market.
However, there are small improvements that i feel could be made.
For example, the addition of hotkeys. This would benefit all keyboard users as it would allow switching screens without having to reach for the mouse.
Another feature would be a heading at the beginning of the main window. The reason for this would be to allow screen reader users to jump to this location without having to use arrow keys as much.
If there is interest in improvement i can point out one or 2 more things that could be improved.



What do you mean by a “heading?” And which window are you referring to as the “main window?”

All pages in Manager are displayed in the same window, with a menu bar at the top. Within this window, there is an active area containing the left navigation pane and the form or view of current interest. That inner area has the business name at the top.

Where would a user jump to and for what purpose? In other words, what is the utility of jumping to some heading, wherever it is on the page, and how does that reduce use of arrow keys with a screen reader?

I think that having the ability to make the program more accessible for disabled users is a good idea, hower it would be a good idea to link up this topic with a recommended guide as laid out by professionals as to what they recommend for various disabilities. The developer can then integrate these features over time and market Manager as an accessible program.

Sorry, I’ll try to explain.
As a blind user i make heavy use of the arrow keys when navigating manager as it is right now.
I’m not personally sure what the layout looks like but i’ll give it a shot.
When in a business i think of the window as having 3 primary sections.

  1. the section containing the “back” button along with “users”, “preferences”, and “support”.
  2. the section that contains the items like “bank accounts”, “invoices”, etc.
  3. The rest of the window which displays the content for which ever menu item was clicked.

The ideal way to do this to me would be to have a heading at the beginnings of sections 2 and 3 as listed above.
This would let the user navigate between sections by pressing one key instead of having to press the arrow key multiple times to navigate through each section.
Hopefully this makes a little more sense now.


Here is a link to a quick google search i did on the subject.
The possible issue with this page is there may be to much info. I personally feel that manager would meet most of the guidelines already so i’m not sure how much more will be needed. The biggest one to me is keyboard support.

Your description of the screen is quite accurate.

This is what I described as the menu bar. The bar itself is at the top, with the Back button at the left. It is part of a large window that contains everything to do with the Manager program.

This is what I mentioned as the left navigation pane. Obviously, it is on the left, below the menu bar.

This is what I called the form or view of current interest. It is on the right, also below the menu bar.

Both your sections 2 and 3 are contained physically inside section 1, within an encompassing subsection headed by the business name. That encompassing subsection has no purpose except to enclose sections 2 and 3 and provide a place to label the business. The menu bar is not included within this encompassing area because its functions apply to all businesses.

Correct me if I’m wrong, but it seems like what you might be suggesting is to have hot keys that would return you to a fixed location in each of the sections. Further, the locations would be headings of some type. Possible choices are:

  • For section 1, the menu bar, jump to the Businesses tab. Although the Back button is at the left, that is probably not a good beginning point for navigation.
  • For section 2, the left navigation pane, jump to the Summary tab, which is at the top. From here, you could also navigate to the only link in the encompassing subsection, which is the Rename link next to the business name. You would visit this link so rarely it seems excessive to define a separate hot key for it.
  • For section 3, the form or view area, jump to the top left field. This will vary according to the form.

I know there are many types of screen readers, including audio, tactile, and simple magnifiers. One difficulty in discussing behavior of them will be that the program now cannot be navigated using arrow keys. Arrow keys function only within fields or to control scrolling. On some entry forms, one can move from field to field with the tab key. So, where a screen reader’s user might employ arrow keys to control which part of a screen display is being accessed, the program’s default behavior is not responsive in the same way.

I’m not personally knowledgeable enough about either the program or operating systems to guess how difficult this would be to implement. Nor do I know how standardized accessibility features are between operating systems. But I assume one would want to utilize built-in capabilities to the extent possible.

Nevertheless, this is an excellent suggestion. As one of the forum moderators, I will put it into the ideas category for discussion and further consideration by the developer.

I was thinking more of a SEN guide to what they recommend should be changed within the program. For example, Windows has an accessibility under accessories, ease of access so it would make sense to start with using that first to control contrast and word size etc and then build into the program whatever windows does not support. I am assuming that Linux and Mac OS would have similar accessibility functions.

I basically think what you want is to use up down arrows to jump from field to field and use the tab key to jump to next function such as invoice, clients, suppliers etc.

OK, Here are my thoughts on this based on the previous messages in this

First, hotkeys. Manager’s UI is rendered as a web page by screen
readers. This is a very good thing and gives additional options to what
i’ll lay out below.

Jump to hot keys.

These are keys that when pressed take you to a specific place on a page.
We can use this because of the web page statement i made above. These
are screen reader specific and already exist so we don’t need to create
the keys, just

elements we can use to make them do what we want to. This is why i was
talking about headings earlier in the thread. This is just one of the
possible elements, i chose it because it’s the one i use the most. It
also offers us the ability to create sub headings if we wish but i don’t
feel like there is enough to make that worthwhile. So if there were
level one headings at the beginning of each section i could cycle
through all 3 sections by pressing the letter h.

The letter h is a screen reader specific command and will work if the
person is using either the jaws or “NVDA” screen readers, but not
necessarily for other screen readers. Other screen readers will have a
similar command though. For people not using a screen reader this does

Command shortcuts.

This is what would make manager keyboard friendly for sighted people.
These shortcut keys should be a combination of 2 or 3 keys pressed in
sequence. Most of us are probably familiar with “control c” as an
example. I’d recommend focusing on the navigation pain and the back
button as a beginning. My personal preference would be to have 2 key
shortcuts, for example, “alt left arrow” for back. I do recognize that
this could limit combinations though so if you’d rather want 3 keys that
could work as well. I haven’t thought through the rest of the navigation
pain and what each option should be so won’t list those out here. If
people want suggestions, just ask.


As mentioned earlier, all screen readers have options for navigating web
pages, these work within manager so this makes the program nagivable as
is, just a bit clumsy.

These controls aren’t standard across operating systems or screen
readers though so i’d recommend letting the screen readers handle the
navigation and just create the command keys section and headings.

Experience level and testing notes.

I should mention here in case no one has figured it out yet, I myself am
a blind computer user and am planning to start using manager at the end
of the year. All the work i have done in manager so far has been in
windows 7, 8.1, and 10. I have not tested it on mac so can’t comment on
accessibility or lack their of there.

The screen readers i use are jaws and

NVDA is open source for those that want to play. Also, the NVDA
developers will be more than happy to help with any development focused
questions if needed.

There was some mention made of windows built in accessibility in this
thread. If using anything older than windows 10 don’t bother testing as
“narator”, the built in screen reader was a peace of junk. Now with
windows 10 it’s better but if the above suggestions are followed narator
should work without needing more work.

Also, as one final note. I know i have focused almost completely on the
blindness perspective here and that is because as a blind user, this is
the part important to me and also what i can speak the most about. If
there are any other accessibility groups out there that want inclusion
in this just speak up, i’m more than happy to discuss those needs and
push for there inclusion into manager, i just don’t happen to know what
they are.


So basically what the developer should be focusing on is integrating Manager with a screen reader such as Jaws or NVDA. That would be a good place to start for what to base Manager accessibility features on.

My point about accessibility features was more to highlight that Windows already has features for things like contrast, high contrast, magnification and changing windows colours, so I was suggesting not to re-invent the wheel. Having said that I don’t know how well the high contrast etc features work as I don’t need them.

One other change that I would recommend for manager is changing the colour/contrast between active tab and inactive tabs as the default is white for active tab and grey for rest. But even though I can see it, for anyone who has vision issues, it would probably be very difficult to see which tab is active. I have always thought that there was not sufficient contrast.

That would be my thoughts as well.

As mentioned earlier, i can’t really comment on the magnification
features built into windows, however, even if those don’t work, there
are third party programs for that as well so no need in my oppinion to
build in special accessibility features for that either.

I do agree with you on white versus gray though, While i am almost
completely blind, for what little site i do have i’m not color blind so
do know the basic difference between colors. For contrast, white and
gray is to similar in my oppinion as well.

I’m really looking forward to seeing what can come out of this discussion.

Have you considered using the cloud version of Manager? I was reading up on Jaws, and I see that Firefox, IE etc are already compliant with Jaws, so if you use the online version of Manager and say Firefox, you should be able to use Jaws. Although I don’t know how much if any modification would need to be made to Manager to make the tabs work as links and the entries work as form controls. Or maybe they already do?

Can’t guarantee any ETA on adding accessibility features to Manager as the developer prioritises program improvements according to difficulty, urgency and other considerations.

I haven’t tried the cloud version, and don’t really have plans to.

The desktop version is usable, i started this thread as a suggestion for
some improvements that i think could be made to make it work even better.

Thanks for the suggestion though, i like what i’m seeing from the
program and community.

Having thought about it, it would make sense to have it working in the desktop version as the key feature of this program is that it is consistent in all versions of the program and I don’t think it requires a lot of programming to make it compatible with Jaws etc. But the developer will let you know what difficulties there are with regards to your request.

I’d like Manager to be responsive to screen sizes. This would improve the look of the program on smaller screens such as mobile phones and as a side-effect, it would make the program much more accessible to screen readers.

I can certainly imagine the pain trying to navigate the program using screen reader as it is now.

I’m curious, how do you visualize automatic screen sizing would make manager more screen reader friendly? I’m not critesizing the idea, just curious as to what your thoughts are and how you visualize it working.
As it is now, manager would actually work pretty well if you were using it on a touch device as long as it scales well to different screens which i think i’m hearing you say it does not.
However, scaling to screens isn’t my biggest issue, keyboard navigation is the biggest issue for me personally at the moment.

Whatever work can be done on that would be greatly appreciated.


Hello all.
If using a screen reader with manager any searchable dropdown boxes don’t work with a screen reader.
If you know what you want you can type it in and press enter and it works but if using the up and down arrows to brows the list of possible results no info is passed to the screen reader.
I believe the visual on screen indicator changes but if you depend on speech to run the program this does me no good.
An example of this can be found in payment entries, when searching for accounts for the payment.
Could this be looked into?


there is already a topic created by you in the ideas category addressing this issue. creating new topics for the same will not help with earlier implementation. please post your requirements or concerns in the same topic.


  Actually, the topic you mentioned is asking for enhancements to

the program.

  This topic is discussing a bug introduced in manager since i

started using it.

  I don't think i can point to a specific version, it's been this

way for at least a year, but when i first started using manager
the example given in the first post on this topic did work.


Hi all.

I’m going to summerize some of the last posts in this topic and add some additional notes from what i’ve learned in the past year.

If using a screen reader with manager any searchable dropdown boxes don’t work with a screen reader.

I’ve figured out since then that this problem wasn’t actually a bug in manager as much as a bug in the web rendering library that manager uses. It has improved in the last year, and now doesn’t work consistently across browsers and the desktop version. This is actually an improvement though as it didn’t use to work at all. I like the decision to use modern webview implimentations as this should bring with it some of the accessibility fixes for specific controls like searchable dropdown boxes.

Having thought about it, it would make sense to have it working in the desktop version as the key feature of this program is that it is consistent in all versions of the program and I don’t think it requires a lot of programming to make it compatible with Jaws etc. But the developer will let you know what difficulties there are with regards to your request.

This is correct, i don’t think either there would be a lot of programing needed. In fact, the desktop version of manager itself is basically working, i’m just suggesting a few enhancements.
These were mostly discussed earlier in this thread and are keyboard shortcuts and consistent navigation points.
Keyboard shortcuts would benifit all users regardless of accessibility while the nav points would primarily benifit screen reader users. I’m going to expand on both below in hopes of providing more info.

  • keyboard shortcuts. What i’m invisioning here is something like what’s talked about in this article. I think i’d do the following for keyboard shortcuts.

    1. have universal two key shortcuts for commands like save, print, email, new, etc. These would work anywhere that the related buttons exist.
    2. have 3 key shortcuts for the left hand sidebar with customers, invoices, etc.
      If this was implimented a user that’s entering data could flip between say the purchase invoice and goods receipts screens quickly without ever reaching for the mouse. It would also allow users to save and create new records also without having to reach for the mouse and greatly speeding up data entry. As i’m writing this, i’m thinking keyboard shortcuts really needs it’s own topic on the forum as it really doesn’t relate to screen readers at all.
  • nav points. What i mean by nav points is a marker at the beginning of each primary section in the manager window. This is already supported natively inside web applications so really shouldn’t require much coding if properly understood. A nav point can be various things, for example, a button, heading, or table. Manager has various of these scattered throughout the program but not in a consistent manner. For example, most screens like invoices that contain searchable data contain a search box above the table of data. Here we have 2 nav points, the edit box for search and the table with data. Users of the nvda screen reader can press the letter e to move straight to the search box and the letter t to move straight to the table. While this is nice the issue here is that there are no consistent points. Consider, if you go to the summary screen we all of a sudden don’t have the search box any more so can’t use the letter e to flip to the start of the main section with the summary data. In fact, there really isn’t a good point to use to go to the start of the data. T doesn’t work because the letter t just goes to the next table in line on the page. In recent versions of manager every item on the left hand side bar is showing up as it’s own table. For example, it shows like this
    So because of this the t shortcut becomes much less useful because there are too many tables.
    I’d like to propose the use of structured headings for sections.
    For example use a

level one heading for the start of the left hand sidebar and the main data section.

Sub headers could be used if necessary and where appropriate.

I’ve probably written enough for now. Hopefully this clarifys my thoughts somewhat.
@lubos, any comments?