Switch Accessible Electronic Books
We want some examples of switch-accessible books on the Scottish Accessible Book Library, so here’s a very basic question: what format should these be in?
A single switch user (or two switch, or someone using IntelliKeys, communication aid, eye-gaze or head-controlled mouse etc) should be able to:
- Open the book from the library
- start reading where they left off
- Navigate through the contents and structure
- Go to a particular chapter or page
- Turn the pages
- Swap between the current page and the contents page
- Change views (e.g. single or two page view, zoom in/out)
- Use Find/Search and index tools
- Add bookmarks, text notes and comments
At the moment, we can build books in say Powerpoint and use a switch to swap slides, but the switch access is pretty limited. Or we could use SwitchItMaker or Clicker but both of these require each page to be made manually by cutting and pasting. Or we could use MS Reader, PDF or EasyReader and program a Crick switch box to give the keystroke commands for turning pages etc. But this doesn’t help a single switch user do more than just turn a page. Or we could create a scanning selection set using The Grid, or SAW, say, or use another switch access system like EZ Keys or AssistiveWare.
I don’t know the best way to tackle this, collectively: do we want an ‘add-on’, say, to Acrobat Reader so that a switch user can navigate around a PDF and access it? Or switch accessible Reader that can read PDF, or DOC, or Daisy books. Or a brand new specification for a switch-accessible electronic book format together with switch reader programs to read the books?
Comments please!
January 17th, 2008 at 2:47 pm
I would like to see you implementing the last idea- “a brand new specification for a switch-accessible electronic book format together with switchreader programs to read the books.” Ideally this would become the standard format for all electronic books. It would also have the facility to import the books easily into its format.
A wonderful dream- a long long way on from the inefficient page-turmers for physical books that we used to struggle to find! Hope it wouldn’t take TOO long?
January 17th, 2008 at 3:27 pm
Well I guess there is no simple answer but here are a few thoughts:
* File Format: if this is an open format other programs can be created to access it. Otherwise you have to stick to a single program or create converters (with possible verse engineering of proprietary formats) You will also probably want batch conversion tools to convert from the source formats. PDF is pretty much an open standard are many tools exist already. There may be Open Source readers that could be modded.
* It may be required to provide other accessibility features as well so compatibility with other AT may be wanted. However that might cause complex interactions and ebooks tend to have highlight and speech options)
* using a new program with builtin switch access may seem to be more controllable but requires all readers to duplicate it or every one to use the same reader. Using a general AT that can control any program (autohotkeys, SAW, GOK, Jambu) allows users choice (but needs an open format too).
So using a standard format with a general AT to control programs should be the most flexible. A new program and format might offer simplified design/maintenance at the expense of user choice and possible lockin.
PS the captcha on this bog doesn’t appear to be accessible to screen reader users (recaptcha is good).
January 17th, 2008 at 3:47 pm
Interesting stuff Paul!
A few inital thoughts. The format should be something simple and open - so it can be transformed into, for example, PDF, Text, Braille, mobipocket, PRC or even image based. The format? Well a few options but the obvious one is docbook http://www.docbook.org/.
Don’t go along the route of a new specification - there really is no need. Don’t reinvent the wheel. A XSLT (style sheet that transforms the docbook) into your own accessible format would be all thats required - along with a few bits of programming to convert it to other non-text based formats. e.g. text->speech.
As you say - A PDF reader can be made switch accessible - map arrow keys to your switches. Whats nice about PDF is that it embeds the fonts and is vector based. It runs on all platforms and because the text is in the file you can use text readers. What nags me most about your post is that its very PC (& windows) biased. What about e-readers and other platforms?
Heard about the amazon kindle? http://en.wikipedia.org/wiki/Amazon_Kindle
It strikes me the question isnt so much about “what format?” as to “what device/software do we use?”. Remember - Text is text - you just need to get the software to read the already available formats and present it nicely.
January 17th, 2008 at 4:10 pm
Thanks for the post. Agree that we need something simple and open, but let’s say we have a docbook file and we convert it into the formats you mention - PDF, text, Braille, etc - none of these are adaquately switch accessible, so the user still has a problem and that’s why I think we need a specification for what a switch-accessible book is - so that we can write the converters and the reader software programs (for Windows, or Mac, or Windows Mobile, or Java….). An effective switch access electronic book reader doesn’t exist - we need a specification for what it should do so we can get it written.
January 18th, 2008 at 8:02 am
Hmm. Its a bit of a chicken and egg problem.
What comes first? The application to read the accessible (be it switch or whatever), or the document format? Now don’t get me wrong - developing a document format makes a lot of sense but you have to know what your application will do. Just seems a little odd to say “what kind of document shall we have” before thinking “what kind of application shall we have”. Microsoft didn’t create the .doc file format first then decide make a text editor to write/read it.
So the question then is surely this: What features are required of an e-reader application that is switch accessible? Your points 1-9 are more of this rather than document spec specific. You could already hack some of the open source PDF readers out there to do most of this - and yes make it switch accessible. (Actually CHM files spring to mind and the numerous readers that exist).
However saying that, XML is a good starting point if you want to sketch ideas out. My suggestion would be to develop a module for docbook - (i.e. rather like simplifed docbook http://www.docbook.org/schemas/simplified ) which you can build into the document various features. e.g. associated widgits with words, etc. You have to realise though that some, infact many, features need not be in a document spec. e.g. font size, font, colour of text/background, page length, bookmarks, page memory, notes and comments & key access would be defined by the application - not the document. Don’t restrict your users as to how they must read your document - its all about accessibility after all right?!
January 29th, 2008 at 2:51 pm
Thinking about this a bit more - so we need a Switch Accessible Document Reader that can read say PDFs, Docbook, DOC, Daisy, text?
Back to the spec - what should it do, and who’s going to write it?