Page 1 of 1

Prioritizing accessibility of different functions

Posted: Tue Oct 23, 2018 7:15 am
by Daniella.LP

Now that everyone has assessed OverDrive in a systematic way, which criteria would you say are imperative for any library application to be usable with a screen reader? For example, if annotation functions are not accessible but it is possible to start reading independently and to navigate a book within a particular application, it may still be usable, even if far from perfect. So in this example, annotation features may be nice-to-have, but not crucial.

We are aiming to provide vendors not only with a list of the issues we find, but also prioritize them in the final reports for them.

Thanks in advance for any and all feedback!

Re: Prioritizing accessibility of different functions

Posted: Wed Oct 24, 2018 7:53 am
by Danny
Good morning,

I would say in the Windows edition, the ability to navigate back to the Bookshelf after selecting a title to read would be #1. Having to constantly close and reopen the application is maddening! #2 would be the ability to move back to the reading pane after selecting a new chapter, and #3 would be a read-to-end feature.

I think what's most interesting about these testing results is the wide array of accomplishments. Am I the only one who didn't find a read-to-end feature on Windows? I'd love to know how to access it, if someone else found it. And is there a way to properly navigate the application without constantly closing and reopening it? I'd love to know.

Regardless of the above, I would suggest that if it's difficult to figure out / make work, it should be updated. But it would help improve the quality of our reports, I think, if we can say "we had to reach out to others for assistance to determine how to utilize this feature."

Under Android, a read-to-end feature would be #1 in my opinion. Relying on a TalkBack gesture to accomplish this is ineffective. Aside from some unlabeled buttons (such as the Return button on the Home screen and the unlabeled TOC/Bookmark tab while reading, no further updates are really necessary. It's a completely different experience under Android, and once I got the hang of it, I found it vastly preferable to Windows.

Re: Prioritizing accessibility of different functions

Posted: Thu Nov 01, 2018 8:34 am
by steve.murgaski
Hello Daniella. Looking through the criteria we've been using, I would prioritize them like this:

Can you sign-up independently? (If there's a captcha, is it accessible?)
Can you login the application with library barcode/pin?
Can you use email to sign up/login?
Can you check out titles?
Can you explore bookshelf/my account for titles on hold and checked out?
Can you return a title?
Can you delete a title?
Can you open a title within the application?
Can you activate the reading function?
Can you begin reading at the last place you were in the file, after leaving the application?
Can you begin reading at the last place you were in the file, after opening a different title within the same application?
Can you adjust the reading speed?

Next highest:
Can you cancel a title on hold?
Can you navigate and use curated lists
Can you access all reference information about the title (publisher, year, number of pages etc.)?
Is it possible to know where you are in the book (percentage, time, page number)?
If the content contains text in different languages, does the application support pronunciation in that language?
Can you check how a word is spelled from within the application?
Is it possible to move from the table of contents to different sections within the book?
Is it possible to navigate a book by headings separating sections (e.g. chapters)
Is it possible to navigate the file by page?
If there are hyperlinks, can you navigate from within a page to a different location within the book?
Can you search for a string of characters and move to the results?
Do all buttons/controls have text labels?
Does the links' text adequately describe what the links do?
Can you access all functions in the app only using the keyboard?

The rest I would group together as lower priority, except the ones for low vision users,which I haven't tried to classify. Sorry for the long post; I couldn't think of an easier way to do it. :)

Re: Prioritizing accessibility of different functions

Posted: Sat Nov 03, 2018 11:35 am
by rmarion
Here is the list of features I would like to see as a priority for eBook reading apps like Overdrive. Before I list my priorities, I do think we need to stress to the app developers and venders that they need to strive for full accessibility of all features of the app. However, if they want to do it in steps, they need to consider the priority features we have listed as crucial.

Ann accessible way to login to your library account using the app. As you may be able to create your account on a website, it is always necessary to login into your library account using the app.
Browsing your bookshelf is important. Being able to know what books you have checked out, when they are due, and seeing hold requests are the most important features in my opinion.
Being able to open and read a book. This should be as seamless as possible. Once the book is open, there should be different accessible reading modes that the user can activate. For example, the ability to read to the end of the book without manually flipping pages should be available.
Being able to set book marks and then either go back to a previous reading position or to the list of book marks should be accessible. This feature may not be as widely used by people reading for pleasure, but it would be useful if a person wants to return to a specific section if they lose their reading possition. ]
These features are only an example of what would have to be done to make apps more accessible. But if these are done at a minimum, it would make the library reading apps more usable for people using screen reading technology to access eBooks.

Re: Prioritizing accessibility of different functions

Posted: Mon Nov 05, 2018 10:07 am
For prioritizing features, I would suggest:
1. Creating an account
2. logging in
3. Being able to access the library of books in the app
4. Being able to read the text of a book using a standardized view and being able to access playback controls in an audio book
5. Being able to access sections of the book by heading/time and jump to time
6. Being able to adjust speed of playback and visual settings for text view
7. Being able to access settings of the app

The ideal of course is to make sure the app is fully accessible but those would be the features that I would suggest working on first if that's the workflow. Another workflow that they might consider is to
1. Make sure all buttons and other standardized elements are clearly labelled for screen readers
2. If there are custom controls used, then make sure accessibility is part of those controls. Otherwise, use standard controls.
3. Now figure out specific playback/settings/visual features that need to be added
4. Examine the workflow with assistive technology and users.

Accessibility should be integral and not a feature. I also recognize that the way programmers create controls really depend on the operating system and libraries being used.However, even though the steps i wrote are simplified, I think it gives developers a starting point that allows them to learn how to make elements in an app accessible before they focus on specific features.