Screen reader accessibility for blind users?

ideas
1

Hello.
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.

Thanks.

3 Likes
2

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?

3

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.

1 Like
4

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.

Thanks.

1 Like
5

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.
Thanks.

6

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.

7

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.

8

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

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
nothing.

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.

Navigation.

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 https://freedomscientific.com and
nvda https://nvaccess.org.

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.

Thanks.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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.

1 Like
15

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.

Thanks.

16

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?

Thanks.

17

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.

18

Hi.

  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.

Thanks.

19

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
    |invoices|2|
    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?

20

I am currently updating my website and one of the new features that I am implementing in my new website is accessibility functionality. I wanted to share my findings in the hope that Manager can benefit from my research to make the program more accessible.

Focus States
Skip Keyboard Navigation
Semantic HTML
Font types, font sizes, colour contrasts
Firefox Reader View, Edge Narrator, Apple Reader mode and dedicated screenreaders like Jaws and NVDA.

There is actually very little coding required to make a website compliant with WCAG - Web Content Accessibility Guidelines. The biggest time consuming aspect for me was deciding on colour schemes that worked with WCAG - the actual css and html coding is really minimal.

A quick overview of accessible websites versus Screen Readers.

If you design your website with very readable fonts, font sizes, colour contrasts, you use semantic html (which one should be using anyway) and you implement Focus states and Skip keyboard navigation, your website will effectively be compliant with AA level 2.1 version WCAG which is the main one to aim for as it’s very easy to achieve this standard with very little work. I would consider this to be the bare minimum for a modern website nowadays. To achieve AAA level does require a lot more work and depends entirely on the target audience of the website in question.

When you create an accessible website that meets AA level 2.1 version WCAG you have implemented the following in the main:

Keyboard navigation for users who don’t or can’t use a mouse. This is quite basic to setup in html and css especially as keyboard navigation works out of the box for websites anyway. It’s a question of optimising keyboard navigation on your website, making it more easy to see which link you are focused on as well as avoiding unnecessary keyboard entry to get to the desired link, which is currently the main problem in Manager.

Support for users who’s eyesight requires a higher level of contrast, possibly larger fonts or more easy to read fonts. This is easily manageable by using a website like Colour Contrast Checker to ensure that all your fonts against the background colours you are using have sufficient contrast for the font size and colour. As long as your website is properly responsive using em or rem for font sizes against a default html font size of say 16px, it’s trivial for the website to scale everything well when a user adjusts the default html size to a larger font causing everything else to scale in proportion. I will say that the contrasts of some things in Manager is not sufficiently high, so it’s not easy to see what is active.

For users who need websites with minimal visual distractions - Firefox Reader View, Edge Narrator Mode or Apple Reader Mode offer the ability for autistic users to view the website in simple black and white, with no visual distractions. This probably is not relevant for Manager.

As such, for a lot of users a dedicated screen reader is not necessarily required as it is possible to achieve an accessible website by doing the above. However, support for keyboard users, users with vision disabilities and last people with say autism for example, a screen reader or firefox reader view etc all benefit if the website is accessible using semantic html, focus states, skip navigation menu etc. So it’s not a question of one or the other. The aim should be to create an accessible website that enables all visitors to use the website optimally and they can potentially use a screen reader to further enhance their browsing experience.

Focus States:

/* Apply focus styles to all links */
a:focus-visible {
  outline: 2px solid red; /* Add an outline for focus */
}

The above will create a red border of 2 pixels when the keyboard is focused on that hyperlink element. That is literally all you need to do to apply focus states for standard links throughout your website. I went with red because Manager’s brand colour is red. This is in your css file obviously. Browsers have a default colour for focus state. The ideal should be to use a colour that works with your colour scheme.

Skip Keyboard Navigation Menu

Css coding

/* Apply focus styles to skip navigation link */
.skip-navigation:focus {
  color: navy; /* Navy font colour */
  background-color: grey; /* grey background colour */ 
  width: 30%;
  height: auto;
  border-radius: 15px;
  text-align:center;
  font-size:1.2rem;
  z-index:100;
  
  /* Flexbox centering */
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

/* Hide the skip navigation link visually */
.skip-navigation {
  position: absolute;
  left: -100%;
  top: auto;
}

This code cannot be copied into Manager and work out of the box as it will depend on the css coding for the rest of Manager. I am just providing it to demonstrate how little coding there actually is to create a skip navigation header.

What the coding does in the skip-navigation:focus area is creates a Skip to Main Content header when you press tab for the first time on the website. It will create the font in navy, with a grey background, a width of 30% with rounded corners and align the text in the center of the header. The font size will be 1.2rem and the z-index needs to be higher than any other z-index to ensure that this header is overlaid on top of any other header.

The flexbox centering section I used to ensure that the Skip to Main Content Header that is visible is in the center of the screenview and horizontally centered in the first element - which in my case will be my header.

The .skip-navigation section basically hides this header off screen so that users who use a mouse never see this.
Then all you need is to call the class in the header

<!-- Skip Navigation Link -->
  <a class="skip-navigation" href="#main-content">Skip to main content</a>

and in your content files instead of you need to have

<main id="main-content">

as you need an “id” called main-content.

Now when keyboard users press tab, they are presented with a header that they can see saying “Skip to Main Content”. If they press enter, then they miss all the links on the navigation menu and go straight to the main content., When they tab again, they go to the first hyperlink in the main content section. This means that keyboard users don’t have to repeatedly scroll through the navigation menu on every single page to get to the hyperlinks that they want on the content page.

You could do similar functionality with Manager to enable keyboard users to browse LHS navigation menu or forms within a tab. The concept is the same really. My understanding is that the main problem with Manager is having to tab through every link on a page to get to the next tab on the LHS menu. Skip Navigation link and possibly hot links coding used appropriately for Manager would address this issue.

Font types, font sizes, colour contrasts

Use the Colour contrast website linked above for good contrasts. Ensure that all your font sizes are em or rem based on a default html font size of say 16px which ensures that Manager is responsive on any screen size, but equally ensure that browser users can adjust the html font size and all font sizes will scale correctly and properly for accessibility. And check with accessible websites about font readability as not all fonts are good fonts to use.

Firefox Reader View, Edge Narrator, Apple Reader mode and dedicated screenreaders like Jaws and NVDA.

If the website has been designed well, then browsers and screen readers can optimise and enhance the browsing experience for all users.

Semantic HTML

Ensuring that all pages follow a consistent format using well established html elements such as:

<!DOCTYPE html>
<html lang="en">

  <head>
    <title>Manager Accounting</title>
    <?php include "head.php";?>
  </head>

  <body>

    <header class="header-white">
      <div class="header">
        <?php include "header.php";?>
      </div>
    </header>

    <main id="main-content">

        <h1>Banking</h1>

        <article>

          <p>payments</p>
		  
        </article>		  
		  
    </main>

    <footer class="footer" id="footer">
    <?php include "footer.php";?>
    </footer>

  </body>
</html>

ensures that browsers and screen readers can easily format web pages when you are using semantic html as the elements will all be standard, common elements. One should be using this for SEO and for good programing reasons as well.

Hopefully this will be of help to make Manager more accessible for various users. As you can see there is very little actual coding to get most of this done - although I suspect that Manager’s html is probably not semantic for screen readers. My website has a navigation menu and main content, so I can’t say how easy it would be to get the keyboard navigation issues sorted for manager as there is a need to jump in and out of forms back to navigation etc and hotkeys for printing, saving etc would be necessary, but all you need is “id’s” to jump to the correct link.

2 Likes