Story: A Screen Reader Salvages a Legacy System

This post tells a story of how the NVDA Screen Reader helped a person with vision loss solve a former employment situation puzzle. Way to go, grandpa Dave, and thanks for permission to reprint from the NVDA discussion list on

Grandpa Dave’s Story

From: Dave Mack
To: nvda

Date: Oct 29

Subj: [nvda] Just sharing a feel good experience with NVDA
Hi, again, folks, Grandpa Dave in California, here –
I have hesitated sharing a recent experience I had using NVDA because I know this list is primarily for purposes of reporting bugs and fixes using NVDA. However, since this is the first community of blind and visually-impaired users I have joined since losing my ability to read the screen visually, I have decided to go ahead and share this feel-good experience where my vision loss has turned out to be an asset for a group of sighted folks. A while ago, a list member shared their experience helping a sighted friend whose monitor had gone blank by fixing the problem using NVDA on a pen drive so I decided to go ahead and share this experience as well – though not involving a pen drive but most definitely involving my NVDA screen reader.

Well, I just had a great experience using NVDA to help some sighted folks where I used to work and where I retired from ten years ago. I got a phone call from the current president of the local Federal labor union I belonged to and she explained that the new union treasurer was having a problem updating their large membership database with changes in the union’s payroll deductions that they needed to forward to the agency’s central payroll for processing. She said they had been working off-and-on for almost three weeks and no one could resolve the problem even though they were following the payroll change instructions I had left on the computer back in the days I had written their database as an amateur programmer. I was shocked to hear they were still using my membership database program as I had written it almost three decades ago! I told her I didn’t remember much abouthe dBase programming language but I asked her to email me the original instructions I had left on the computer and a copy of the input commands they were keying into the computer. I told her I was now visually impaired, but was learning to use the NVDA screen reader and would do my best to help. She said even several of the Agency’s programmers were
stumped but they did not know the dBase program language.

A half hour later I received two email attachments, one containing my thirty-year-old instructions and another containing the commands they were manually keying into their old pre-Windows computer, still being used by the union’s treasurer once-a-month for payroll deduction purposes. Well, as soon as I brought up the two documents and listened to a comparison using NVDA, I heard a difference between what they were entering and what my instructions had been. They were leaving out some “dots, or periods, which should be included in their input strings into the computer. I called the Union’s current president back within minutes of receiving the email. Everyone was shocked and said they could not see the dots or periods. I told them to remember they were probably still using a thirty-year-old low resolution computer monitor and old dot-matrix printer which were making the dots or periods appear to be part of letters they were situated between.

Later in the day I got a called back from the Local President saying I had definitely identified the problem and thanking me profusely and said she was telling everyone I had found the cause of the problem by listening to errors non of the sighted folks had been able to see . And, yes, they were going to upgrade their computer system now after all these many years. (laughing) I told her to remember this experience the next time anyone makes a wisecrack about folks with so-called impairments. She said it was a good lesson for all. Then she admitted that the reason they had not contacted me sooner was that they had heard through the grapevine that I was now legally blind and everyone assumed I would not be able to be of assistance. What a mistake and waste of time that ignorant assumption was, she confessed.

Well, that’s my feel good story, but, then, it’s probably old hat for many of you. I just wanted to share it as it was my first experience teaching a little lesson to sighted people in my
own small way. with the help of NVDA. –

Grandpa Dave in California

Moral of the Story: Screen Readers Augment our Senses in Many Ways = Invitation to Comment

Do you have a story where a screen reader or similar audio technology solved problems where normal use of senses failed? Please post a comment.

And isn’t it great that us older folks have such a productive and usable way of overcoming our vision losses? Thanks, NVDA projectn developers, sponsors, and testers.

Hyperlinks considered Harmful! On to structured Reading.

Our changing modes of reading

This post visits topics heavy on web technology, with troubles well beyond vision loss. The previous blog post describes my current reading regime with print disability and technology adaptations. I find common ground with an article in the summer 2008 Atlantic Monthly and assorted blog commentaries bemoaning information overload and discomfort induced by chronic web use. I draw on some related resources from my audio channels of interviews and reviews. The central question is how our plastic brains are reprogrammed by our reading technologies, emphasizing the stresses and joys we find operating in a tug-of-war over what controls our reading lives.

Why is it hard to read a whole article?

The July-august Atlantic Monthly features an article that asks "Does Google Make Us stupid?" . This title suggests an excursion into declining abilities of critical analysis. Rather, the discussion is the gnawing sense that the structure of interactive media combined with pressures to assimilate lots of online information is actually changing not only reading habits but also brain structure. I found this thesis fascinating from my own experience of deliberately rebuilding my reading life and knowing my brain was re-wiring itself for auditory rather than visual input of words and written thoughts. This is pretty profound stuff.

Ugh, the article’s title itself is kind of stupid, a touch by an editor rather than the article’s author. Indeed, Google is described as a monument to measurement technology in attempting to achieve the best all-around responsiveness to user queries, up to trying to read minds as represented by query histories. That’s a worthy game and has changed the world but is not the crux of the article. The key idea is that a hyperlink from a web page you are reading is not only a reference but a propellant toward action, as Carr describes its effect. In the context of technology that encourages multitasking, impulsiveness, and need to be interlocked with others on myriad networks, hyperlinks could be considered harmful. Note: my hyperlink references are at the bottom of this post.

The analytic tradition of ‘XX considered harmful!’

The phrase ‘XX considered harmful’ is a tradition in computer science, canonized by the late E. W. Dijkstra in a 1968 article where XX was ‘goto’, a programming construct. He argued that the goto statement in languages like the then dominant FORTRAN caused unnecessary errors and difficulties in reasoning about programs. Somebody tracing through the flow of code would encounter a goto then need to branch their thinking into the continuation of line-by-line code flow as well as taking up where the goto said to go. The problem was also at the other end, when reading code, you had little way of knowing what other code might jump there under unknown conditions. This generated a decade of articles and result that showed both theoretically and practically, very few occasions required a literal goto, that more attention to the algorithm led to code better organized using loops, cases, and exceptions. For example, a well designed loop could be replaced by a logic description of the changes made, no matter how the iteration was accomplished. After the ruckus died down, there were improvements in languages, practices, and pedagogy called the age of Structured Programming.

<h3?Wherre is the harm in using hyperlinks?

My question here is whether the complaints against the goto and the hyperlink are a useful analogy. Suppose I put a link here to the Atlantic Monthly online website. You might be tempted to stop reading my article right here in order to get to the original context. That’s perfectly legitimate, but will you return to my thought stream or continue branching from the magazine article? or start a whole new thread of interest? Can you hold all the branching structure of your day’s reading in your brain and browser history? This is a cognitive dilemma for both reader and writer, stemming from a simple html element. Our scholastic training to cite sources and to help the reader use hypertext technology to reach the source in an instant causes some grief for all of us.

Carr and others are saying that hyperlink-driven reading is making it more difficult for them to read longer articles in printed or online form and even reducing their ability to read books. Is this a genuine loss of some cognitive ability? or is it just a change in reading habits? In either case, is the effect reversible? As some blog comments suggest, maybe there are other reasons for the expressed discomfort, like burn-out, aging, or natural shifts of interest.

Where did hypertext fall apart?

This discussion hit home for me for several reasons. I was a student of hypertext theory in previous career incarnations in the 1980s. Questions then were about types of links, e.g. clarifying, refining, challenging,… To cite one major example, Robert E. Horn elaborated numerous models of hyperlink for different kinds of documentation and uses. Design theorist Horst Rittel evolved the concept of issue-based information systems to address ‘wicked problems’, characterizing difficult social problems requiring intense collaborative analysis. This truly was the golden age of structured Hypertext before the WWW came along and offered goto style hyperlinks to everybody.

For my new reading style using a screen reader, hyperlinks are more often annoyances, as advertising, navigation’s, privacy notices, and 100s of links I never plan to click but must traverse or avoid in order to get to the content of a web page. This means hyperlinks consume personal energy, which may be a partial cause of current reading discomfort. Every inline hyperlink is a decision point – go there? do that now? or later? abandon this article? If we made all these decisions consciously, we would feel even more the personal energy drain. I have learned how loss of visual acuity forces more attention toward energy management to accomplish most reading tasks and to overcome inevitable errors.

Since I went through a period of several months of painful reading, I have a tremendous appreciation for the reading technology I can now use effectively, as discussed in my article on ‘tools, Materials, and strategies for Non-visual reading’. I really did almost lose it, not from attention but from sensory change. I still marvel that my brain can interpret the sounds coming from a synthetic voice and absorb the content as fully as I used to visually, or at least I think so. Wow, a synthetic voice is just a data file and algorithm, but what a difference these make to the print-disabled world!

Does audio reading make hyperlinks less harmful?

As I rebuilt my reading skills, I have come to visualize my reading content as mostly a tree of subjects and articles, retrieved primarily by RSS, and represented in text and mp3 files. If I count in a half dozen daily newspapers retrieved by a pipeline of blind services, every day yields easily over 1000 articles, cached or retrieved by wireless. Reading this way, maybe 50 articles a day, is a very well controlled process because the temptation to take a hyperlink is very rare. In other words, my RSS client and News stand control me while I control my web browser. Although my ICON PDA supports hyperlink activation, my decisions are simpler without a browser. Do I read this article or not, based on title and context in the tree? do I read politics blogs now, later, or skip for a while? Which topics are sufficiently intriguing to switch into browsing mode for searching and exploration? When the tree gets disorganized or its retrieval profile changes, how do I reorganize the branches? all this helps reduce context switching and clicking through regions of inactivity. My non-visual reading regime seems to be much more structured than formerly, more focused on textual content than on links and relationships.

Yet, when my Icon Mobile Manager required a 2 week trip for repairs, I rather welcomed the respite from those 1000s of articles. I had to get my news the old-fashioned way, by airwaves on TV or radio, or by visiting websites. I was amazed at how much work I had to put in to set up the feeds and patterns I had evolved over a year with my Icon assistive technology. Upon return home of the Icon, I trimmed out a few feeds that seemed redundant or left over from previous interests, but mainly I place more time limits on my article reading. It also helps to have the Democratic party race out of the way.

Rregarding books, I do tend to skip around much more than in the past. Because I have a rich library of book files to choose from, I am evolving new interests and Reading patterns. I don’t need to feel bad about not finishing a book as it can still reside on my memory card in an out of the way folder. As to concentration, most of my reading is insomniac style or on the road or for book clubs. Hey, maybe that’s what carr and others need is a social book club with a list of questions for reading and discussion — Do guys do that?

Is there ‘structured reading’?

Ok, I am starting to ramble here. I have suggested the analogy between ‘goto considered harmful’ and ‘hyperlink considered harmful’. My reading program with controlled separation of RSS delivered material from freestyle web browsing could be dubbed ‘Partially Structured Reading’.I share, indeed I just know, that my brain has adapted to the forced changes of print-disabled reading styles by evolving its own techniques for decision-making, context-switching, and stack management. In my view hyperlinks cause two forms of harm. First, they encourage divergence without the convergence and summarizing techniques that enabled overcoming the analogous ill effects of the goto statement. Second, the current hyperlink HTML element that simultaneously expands and binds the web is a primitive instrument that cannot be used for serious thought without imposing some of the rigor of early hypertext theories, e.g. the purpose of the link.

Some more observations on reading as a cognitive activity

I’d like to bring up a few more references on this topic from my audio channels and personal experience:.

  • Former Microsoft executive Linda Stone has laid out our syndrome of ‘continuous, partial attention’ in a fascinating podcast. She asks the fundamental question: do you really want to live that way?

  • A book on ‘distraction’, as interviewed by the wise Diane Rehm on WAMU, details a reform program for teaching attention skills in k-12 to enable a transition from pure information greed to appreciation of facts and policies, e.g. those faced in health care and basic civics.

  • Another book on my wish list, mentioned in the Atlantic Monthly article, is ‘Proust and the squid’ by Maryanne wolf. As interviewed on Brain science, points out that reading is not natural but rather highly contextual in culture and the current technology, whether stone tablets or networks. Scientifically, a lot is going on to show how the brain is truly plastic, evolved to rewire for different styles of processing information.

  • The ultimate brain deconstruction exercise is that of neuroscientist Jill B. Taylor who witnessed the dissolution of her cognitive and physical abilities during a left brain stroke. She then used her right brain sensitivity to guide her rehabilitation, taking this further to remolding her personality. A wild-ass theory I conceived from her description of the limbic system, the so-called reptilian brain, is that perhaps hyperlinks trigger a fight or flight response that might underlie the discomfort of web surfing – every hyperlink suggests a danger or defensive curiosity, lurking at the end of link. The good news she suggests is that these autonomic responses only lack 90 seconds, after which the more rational or familiar emotional thinking is in control. She reminds us that humans might consider themselves as thinking beins with feelings but rather we are primarily feeling processors which think some times.

  • My monthly book club chose ‘The Uncommon Reader’ by British playwright Alan Bennett. This novella traces the Queen’s life style changes from a chance encounter with a mobile reading van, through selections and borrowings of an increased number and variety of reading materials under the tutelage of a Human resource (servant) Norman and the interventions of MBA style queen handler sir Kevin. As the Queen becomes more intrigued with common lives, her relationships with her Duties and supporters changes, discomfiting many whom she interrogates about their reading preferences. Eventually her reading turns into extended reflection expressed in writing and, upsetting everything, a full blown urge to compose a book. While humorous, the novella asks many more serious questions. How does anybody gain or lose in total life experiences from their reading patterns? what does it mean to one’s colleagues to have an active reading program, and also be open about it? To oneself, what are my selection criteria for books, characters, plots? Is reading books an optional life activity or an ingrained part of one’s personality and character? would this royal opsimath enjoy wikipedia and Google?

what these studies lack, I suggest, is investigation into the non-visual ways of working, based in visual memories, alternative styles of work, and so-called assistive tools.

References with Hyperlinks

Here come the hyperlinks!

  1. ‘Does Google Make Us stupid?’ by Nicholas carr in July-August 2008 Atlantic Monthly online
  2. Nicholas carr’s blog ‘rough type’
  3. As Your world changes blog posting on ‘tools, Materials, and strategies for non-visual reading’, posted June 15 2008>
  4. Robert E. Horn’s work on Hypertext theory
  5. Wicked Problems and Issue-based Information Systems from Wikipedia
  6. ‘considered harmful’ background in Wikipedia
  7. Interview on ‘distraction and democracy’ by Diane Rehm on June 8 2008 for book ‘Distracted: The Erosion of Attention’ by Maggie Jackson.
  8. ‘Proust and the Squid’ book by Maryanne Wolf as reviewed by Ginger Campbell on Brain science Podcast #24 and #29
  9. Podcast speech by Linda stone on ‘continuous partial attention’
  10. ‘My Stroke of Insight’ by neuroscientist Jill B. Taylor
  11. Novella ‘The ncommon Reader’ by Alan Bennett, available on
  12. Shrink Rap Radio Live #10 psychologists’ reflection
  13. opsimath definition – one who learns late in life

    Synthetic speech reading of this post

Need a second medical opinion? Try the Controversy Discovery Engine.

A better way to search for analytic web content??

This post offers a way of searching for more diverse and analytic results using a simple web form interface to Google. This approach is especially useful when you are looking for a second opinion, evidence, or authorities on topics like we sometimes face with vision loss. It can also make querying and searching more efficient for our weary fingers by slicing off less useful results from searches. Please give it a try and let me know if it improves your searching.

Searching for better information on ‘myopic degeneration’

First, some background. My recent Retinal Specialist appointment provoked my curiosity as my Myopic Macular Degeneration (MMD) seems to have stabilized. I have been wondering about origins and distributions of this condition, as I have only met other MMD people on the more comprehensive Macular Degeneration earlier post. There’s always a sliver of hope for improvement, possibly from research driven out of the U.S. by stem cell policies. And, always, looms the now effective intervention of repair surgery or injections for retinal detachments or so-called “wet” conditions.

Time to update myself, so I go to Google and find the usual results for the query "myopic macular degeneration". Top results are mostly generic overviews "MMD is related to AMD", but I also find a lengthy Myopic Manual.

Embellishing searches with controversy-related terminology

Fourteen years of searching has taught me I might need to go quite fa r down the Google results list to get into more in-depth discussions. I really wanted to know about the controversies, debates, arguments, and even spats in the related field of ophthalmology, genetics, nutrition etc. So, why not just add the word "controversy" to the query. Indeed, I see different results, but why stop there? Speaking linguistically, and assuming Google is fairly literal, I might want to use variations such as "controversial" or "controversies". Then the thesaurus adds synonyms such as "debate", "argument", "disagreement", and many more, each with variants. Now, I also want supporting material so I might ask for "evidence”, “proof”, “hypotheses”, “opinion” and all these variants. This is a lot of decision making on synonyms and support and variant, typing each and saving for reading those interesting results.

A simple form customizes controversy-related content

Primarily, I am getting deeper and faster into the subject matter. Is there a better way to query Google to achieve these goals? Well, yes, as I tried 5 years ago and dubbed the Controversy Discovery Engine. Go ahead and try it. Type your query into the search box, choose a controversy synonym, optionally select a kind of support, and hit the button. Your embellished query will be sent to Google, asking for 50 results. That’s all there is to it. You might or might not get better results than your hand-crafted queries but at least you now have a lot of packaged queries with just a few extra clicks.

An experiment on ‘Do search engines suppress controversy?’

Why do I claim this approach often works better? Well, driven by curiosity, I performed an empirical study on "Do Search Engines Suppress Controversy?" that was published in First Monday January 2004 online. Now, it’s not that search engines or search engineers have political agendas, but rather just an effect of the link popularity strategy that makes Google search work so well. The web splits into an Organizational web which links the promoters, explainers, and associations for a topic apart from the Analytic Web that includes scholarly papers, blogs, white papers, individuals, etc. The Organizations link among each other and people link to organizations more than the Analytic Web pages are linked to from the Organizational Web or within the Analytic Web. This pushes controversies down the list of search results. Usually controversies are hard to name in queries and you need to know the controversy exists by some name to query for it.

For example, one controversial aspect of Albert Einstein was whether the first wife he dumped had contributed rather more to his research career than was acknowledged. Query for "Albert Einstein AND Mileva Maric" and, voila, the controversy is revealed in various levels of details and with arguments on both sides of the story. Bet you didn’t know that! Using a synonym for controversy raises pages that discuss his personal life and produce the names, like Serbian physicist Mileva Maric, for additional searches. This particular revelation ebbs and flows with the tide of publications on his work and life. So, our approach is to use the language of human endeavors that involve research and the give-and-take of the intellectual marketplace to morph our searches more into the Analytic Web.

More seriously, for medical conditions, people facing surgical decisions want all and the most authoritative information they can get as fast as it can be found. So we offer the Controversy Discovery Engine as a kind of “second opinion” information seeker. Please provide feedback and suggestions to This web page may also be modified for similar uses with appropriate link and acknowledgement. If you’re intrigued with this topic, which won me the proverbial 15 minutes of fame in the blogosphere, read the paper and its five examples: St. John’s Wort, female astronauts, Albert Einstein, Belize, and distance learning. For the real search gurus, the software instrument used in this experiment, dubbed twURL, is available for licensing.

For visually impaired readers, here is a bit more advice. The web page has four form elements with the search query edit box at the top and submit button at the bottom and two list boxes with multi-selection in between for synonyms and support. You can multi-select from the list or select NONE as the last list item. Remember to turn on the virtual buffer in a screen reader to type in the query and select from the lists. Using sight, you might want to pump up the text size using your browser, e.g. Control + in Firefox. If you use this page a lot and know how to edit HTML, save the page and customize its style to your taste.

Try searching more diversely and deeply into the Analytic Web

So, nothing to lose and possibly lots to gain, check out the Controversy Discovery Engine at and let me know how it works for you.

Hear me stumble — web accessibility observations

This posting lists several good and bad examples of web accessibility and usability situations in an instructive sense, including recorded sessions of this intrepid logger guiding her web page readers.

Background Postings and Standards

recurring Problems that are easily fixed

  1. Problem: useless links click Here — huh, for what?

    The unfortunate user must expend extra energy to read surrounding context to find what the click is for. This mistake usually indicates poor communication skills and lack of testing using a screen reader. variations include: Learn More, read more, and the especially illuminating here. similarly, a document may be identified then followed by its type a line like PDF or HTML or size 5 MB.

    Recommendation: Page content writers should read out loud the list of links by screen reader or by eye scanning and assure clarity where each link leads. And there is no excuse for not using a screen reader with the nvda, free, open source, easily installed screen reader .

  2. Problem: blog postings blocked by links — when good blogs go bad.

    conventional web layouts contain site navigation, rolls of links to related content, meta data about site and author, news, etc. screen readers follow a left upper corner, top, left, order that forces reading or bypassing links to reach actual page content, which sighted readers look for in the middle of a page. a repeat visitor rarely has interest in these links. blog and other content management systems usually provide a choice of page layout Reading a links-first blog format takes up screen reader time, even with a jump to heading. More disastrously, an RSS client often receives all the links on a text version of a posting, taking a minute or more to read before content, making some blogs effectively unbearable in RSS format.

    Recommendation: Design pages and choose layouts to favor quick access to recurring content, placing honorific stuff right and below what your main page matter.

    Examples: two of my favorite tech blogs, Good example: Jon Udell blog and Bad example: Phil windley’s technometria.

  3. Problem: Learning the structure of a page — it’s the headings, stupid!

    we all know to sprinkle headings through our documents to break into and describe sections, even applying this to bills and forms. for a screen reader user, headings provide the primary way of moving among sections, often preceded by an exploratory “heading tour” to identify the page sections ahead. without sections, the screen reader’s finer detail units are links, lists, and paragraphs, but this rapidly degenerates into interminable tabs and keystrokes like taking steps into a cave without knowing where the path will lead. conversely, a well-sectioned document also broken into pages can be very rapidly browsed with a screen reader, perhaps even faster than a scrolling sighted reader. can cover graphics and font styles. Chunks of text can be skipped for more detailed reading later. Nothing substitutes for having a sense of the page’s structure in outline form.

    Recommendation: Make sure all page sections are well described by HTML H1, H2, H3,… headings with informative descriptions. Now, is that so hard?

    Examples Good example:”> program organized by days and topic and Good Example: browsing wai-aria documentation

  4. Problem: switchingfrom browser to an external app — .txt imprisoned in .doc or .pdf

    Browsers are now integrated with external applications like Microsoft word or adobe PDF. but that meanss a screen reader user must first launch that app, and, of course, MS OFFICE is not free! reading the document involves a different set of keystrokes and conventions with PDF often losing any previous document structure. Ironically, frequently, the document being read is little more than text any way! This vision Loser simply saves DOC or PDF and then strips the document down to TXT for reading in Notepad or on an external reader like APH Bookport or Levelstar Icon. With gratitude, another path is google search “View as HTML” and HTML save As in mobile gmail. This argument also applies to mail attachment — imprisoning text memos in a WORD format attachment requires a lot of extra work by a visually impaired recipient, and “click on attachment” is often a security risk.

    Recommendation: Web authors should save a version of a document as HTML and Make that a primary link, offering a PDF for portability (that’s the P in PDF). HTML is the document format that literate web writers should be using, e.g. to exploit hyperlinks, and not at all the private domain of web designers and New Media or IT departments. Strictly speaking any PDF should be produced in accessible format for extensive reading.

More complicated web accessibility Problems

  1. Problem: Locked out of the chat room — social Media Overkill.

    recently, one of my favorite podcasters started live chat sessions with call-in. I wanted to ask a question and join in so showed up at the web page at the appointed time, having pre-registered and browsed the site the day before. Uh, oh, I couldn’t find an entry point, didn’t even know what I was looking for. worse yet, an audio had started playing – was that the current session? No, it was prerecorded, drowning out my screen reader with no way of silencing the cacophony. Eventually I waded through a ton of links to other shows, popular podcasters, special offers and found a PLAY button. Now, all this with a screen reader contending with an audio discussion, and then the text chat was completely inaccessible to the screen reader. well, that podcaster lost a fan’s admiration for choosing BlogTalkRadion as a meeting place uncomfortable for me. The key problem was that the main purpose — to bring people together — was obscured by the now socially acceptable business practice of trying to draw attention to other podcasts and \shows – current, popular, categories, rated, which we term “social media over-kill”.
    The irony is that the blind and visually impaired communities have superior chat facilities, as exemplified by accessible, built on Talking communities supporting happily chatting friends of Bookshare book club meetings.

    Recommendation: when choosing a hosting service, check out its accessibility policy, not just how free it might be, if you want to retain your whole audience and its respect. service providers, please write and follow an accessibility policy and stress its use to service users. service providers, content management system designers, and designer assistants all have a great social responsibility – and opportunity – to be inclusive and to educate service users.

  2. Problem: Muddled, missing, mixed use cases — accessibility and mobility needs are met together.

    consider if you know exactly the book you want to buy at amazon or another big web seller. a trip into amazon takes you through myriad departments of other types of products, offers Recommendations, specials, bundles, and even a chance to become a reseller yourself. but all I wanted to do was get that one book into my cart! Well, luckily, limited screen space on phones and PDA’s is leading to overhauls of web sites to alternatives that offer simple and straight paths to the most common goals for impatient, on-the-go users. contrast clutter full scale with accessible, mobile . Now, not all of Amazon is on the accessible alternative, and they don’t tell you what’s missing, e.g. changing an e-mail address in profile.

    Recommendation: web designers can take the opportunity to produce an accessible version of a site along with a mobile-friendly or mobile-optimized version. and don’t forget to tell screen reader users with a non-intrusive link at the top of the page to the alternative. and, save the specials and Recommendations until after the sale.

  3. Problem: forms take forever to fill out and an error can be costly, causing form-o-phobia.

    It’s not just me, the usability literature notes something like 5 times longer for visually impaired form-fillers than sighted users. problems include: identifying required versus optional and what actually goes in a field; non-standard formats for dates, social security numbers, phone numbers; unpredictability of length of forms; time-outs and site failures; and difficulty finding the notification of errors or requirements for verifications. Then there are all those registration “opportunities”, without explanation of benefits of registering, without acknowledgment of the pain to be incurred. No thanks, no forms please.
    Is there a better way? Maybe, as suggested by Jon Udell’s article on batch form-filling for civilians suggesting the use of text strings completed by simple editing and input to an API or query processor. geez, this is so brilliant!

    Recommendation: web designers should take every care to label all fields clearly and acknowledge the time and pain of a visually impaired user. If possible, watch one of us use your form until you cannot stand the pain any longer. and recognize the difference in skill levels and experience and tenacity of a broad audience. forms are where you capture or lose a client. and, don’t even think of putting a graphic only CAPTCHA at the end at risk of eternal damnation. On the other side, visually impaired users need to practice form-filling and accept it as a necessary evil that could ruin your day. We all need to look for better ways, like Jon Udell’s text line suggestion.

Personal Observations and Grand Claims

With a year’s experience using a screen reader, I am still a novice and use articles like this to apportion responsibility for failures
to accomplish web tasks. With a 4-decade career in computing paralleling the lifetime of the Internet, I am acutely aware of many sources of failures: selection, training, and skill level with software, like browsers and screen readers; network and workstation architectures that dictate performance; application requirements analysis and design, as in web 2.0 interactions; educational backgrounds and career motivations of web designers; human proclivity toward ascribing beauty to color and graphics I can no longer appreciate; the levels of personal, team, and enterprise processes that influence application usability; the immense costs of maintenance and upgrade of web sites; and now, the structure of the assistive technology industry, the many human factors of accessibility, and the social resistance to disability issues. Mainly I am trying to take responsibility for building my skills to remain productive in society, and especially to pass along technology lessons to other Vision Losers.

Rarely am I completely stymied but far too often the energy required is the limiting factor. I use the “minimum of 5 times ” rule to estimate effort required for a task, based on memory of past trials. Often, just the thought of the work involved deters me from trying a web site, like registering and then facing a CAPTCHA, maybe putting off to a future idle day. Flippantly, I wish all young web designers would test their web sites during a bout with the flu, so they might appreciate the effects of reduced energy on every click and key stroke.

A second observation is how much the web is overly populated with extremely complex web sites, exacerbated by the trend to social media linking. Every link bypassed in a blog or information page is a decrement in energy available for reading, navigating, information seeking, and transactions. Web designers often seem to cram too many functions onto pages and fail to identify the primary use cases and prioritize for screen reader users. I am delighted at the trend toward mobile friendly pages as very helpful in countering complexity and offering redesign opportunities.

In recent discussions with web accessibility practitioners I sometimes found myself thinking as the beggarly, or maybe miserly,old lady who could not shell out $1000 for an industry standard screen reader like Jaws or Window Eyes and got stuck with a third world open source software tool. There is some truth in the monetary argument as I fail to fall into the social services classes: veteran, worker, job seeker, student, or poverty level. But I have also made a technical choice in screen reader, nvda, based on confidence in its developers, satisfaction with its early capabilities, ease of use and installation, and belief in the efficacy of the open source model of development. I also am concerned at a shaky industry chain of developers, screen reader vendors, and rehab organizations that will soon be coming under more international pressure as a free screen reader takes hold in other countries, perhaps with easy adaptability for local languages and web conventions. I cheer for the Australian Torvalds of assistive technology.

Finally, I find myself moving away from the PC and browser with increasing use of the Levelstar Icon PDA. News comes from the NFB News line to Bookshare to the Icon’s Newstand without a visit to a slow web site. Blogs and feeds bring more news from CNN, USAToday, CNET, and many political and professional organizations — again obviating a browser session in favor of RSS. And the Icon’s little browser often suffices for comfortably reading search results, pages, and blogs not embroiled in JavaScript/AJAX interfaces.

Ok, hear me stumble! Listen to recorded sessions.

Here are two recorded sessions of screen reader uses at Amazon and Fidelity. The Amazon demo follows me through the process of getting a pre-selected book into the cart, using the newer accessible and the classic web sites. The Fidelity example shows an exploration of a web site that has its whole enterprise mapped into menus.

Is there a Killer App for Accessibility?

This post speculates about alternative changed futures for accessibility, such as cost-busting open source developments; self-voicing interactions; over riding inaaccessibilityty by proxy web servers; a screenless, voiced, menu-driven PDA; and higher level software design practices.

An mp3 Youtube converter converted me!

First, I digress to tell you about a cool utility that invoked the serendipity behind this posting. Blind Cool Tech has a podcast, Jan. 1 2008, on a “You tube to iPod converter”. I haven’t used much since the videos appear to my partial sight as white blobs with some hand waving going on. Last week, I began to rethink my intellectual aversion to mindless drivel I feared populated Youtube and affronted my blindness sensibilities. The NYTimes had a piece on “Big Think”, a Youtube for eggheads that promised a variety of magazine-style videos of the ilk that interested me, namely politics and economics, reminiscent of the university-based video series at research

Wow, this little piece of software Youtube to iPod converter really delivers and opened up a new way for me to get useful web information. The use case is: copy the URL for a video that interests you, the link you would click to invoke the viewer; paste the link into the accessible converter; choose a file name and location; choose the format type mp3; click “download and convert”; wait a while; listen to the mp3 or your PC or send it on to a digital player, in my case my Bookport from With a bit of imagination and patience, you can mentally fill in the video and also have a version to replay or bookmark. Moral of this digression: once again podcasts from the blind community open new worlds for us new vision losers needing accessible software to stay in the mainstream. Thank you, blind cool tech podcaster Brandon Heinrich! Check out my page of Youtube converted videos on eyesight-related topics.

Youtube video on WebAnywhere Reader

By sheer luck, the first You Tube search I chose was the term “screen reader” and it turned up a provocative demo and discussion:

University of Washington Research: Screen Reader in a Browser by Professor Richard Ladner and graduate student Jeffrey P Bigham in the Web Insight project at cs.washingting .edu

Briefly, this experimental work addresses the problems of costly screen readers and the need for on-the-fly retrieval of web information by blind users away from their familiar screen readers. The proposed solution is a browser adaptation adding a script that redirects web pages to a so-called proxy server that converts the structure of the page, known as its document object, to text and descriptions that are returned to the browser as speech. This is pretty much what a desktop screen reader does, only now the reader and speech functions are remote. Of course, there are a gazillion problems and limits to this architecture but it appears to work sufficiently reliably and rapidly to achieve the social goals of its name, “Web Anywhere”. This research project, funded by the National Science Foundation, has also used the above architecture to modify web pages to add ALT tags from link texts, OCR of the image, and social networking tagging of images. Not only is the technology very clever, but also the work is based on observations of how blind users use the web and on a growing appreciation of the complexity and often atrocious design of web pages and use of AJAX technology that frustrate visually impaired web users, no matter the power of their screen readers or magnifiers or their skills.

As a former employee of funding agency NSF, a reviewer of dozens of proposals, a Principal Investigator in my sighted days on Computer Security education using animation, let me tell you this U. Washington project is a great investment of taxpayer funds. The work is innovative, well portrayed for outreach at at, addressing monumentally important global and social issues, and helping to bring about a better educated and motivated generation of developers and technology advocates on accessibility issues.
Now, is this proxy-based architecture the killer app for web accessibility? Possibly, with widespread support of IT departments and developers, but the project sets it goals more modestly as “Web Everywhere” for transient web uses and possibly more broadly to address the cost of current screen reader solutions. Maybe the proxy-based approach can be expanded to other uses in demonstrations and experiments on a range of accessibility problems.

Will free screen readers shake up the rehab industrial world? My pick is NVDA

In one sense, a no-cost screen reader provides a way of breaking up the current market hierarchy, which one might unfortunately describe as a cartel of disability vendors and service providers. Yes, the premier screen readers sell for $1000 which seems justifiable by the relatively small market, the few million U.S. and international English-speaking PC users who are blind and on the rehab grid. Some, like Blind Confidential blogger, blink, and industry insider suggest the assistive technology industry is doing fine financially, able to afford more R&D and QA, and attractive to foreign investors. Like any segment of the computer industry, buyers become comfortable with the licensing, personalities, training, upgrade policies, and help lines so therefore resist change. In the case of the $1k products, buyers are more likely not individuals but rather rehabilitation and disability organizations with a mandate to provide user support through a chain of trained technical, health, and pedagogical professionals. A screen reader like the NVDA nonVisual Desktop Access from will challenge this industry segment as more users find it suitable for their needs, as I have written about in“Look ma, no screens! NVDA is my reader” posting . With broader acceptance of open source as a reliable and effective mode of software enterprise, as nvda co-develops with other flexible open source office and browser products, as energetic developers fan out to other accessibility projects, well, nvda might well be the killer app of cost and evolution.

Should apps depend on screen readers or be self-voicing?

However, in a more radical sense, I argue that the screen reader model itself is badly flawed and that also technical accessibility alone is inadequate to resolve the needs of blind web users.

The value of a universal screen reader is that it can do something useful for most applications by dredging out fundamental information flowing through the operating system about an application’s controls and its users’ actions. But another model of software is so-called “self voicing” where the application maintains a focus system that tracks the user’s actions and provides its own reactions through a “speech channel”, providing at least equivalent information to an external screen reader. Such a model can do even better by providing flexible information about the context of a user event and preferences. A button might respond upon focus with “Delete”, or “Delete the marked podcasts in the table”, or repeat the relevant section of the user manual, or elaborate a description of the use case, such as “first, mark the podcasts to delete, and here’s how to mark, then press this button, and confirm the deletions, after which the podcast files will be off your disk unless you download them by another name”. Self-voicing as speech technology is implemented by many applications that allow choice of voice, setting speed, and even variation of voices matched to uses, e.g. the original message in an e-mail reply. More significantly, self-voicing puts the responsibility for usability of the application directly on a developer to provide consistent, coherent, and useful explanations of each possible user interaction. Further, this information is useful both to the end user and to testing professionals who can check that the operation is doing what it says, only what it should, and in the proper context of the application’s use cases. Ditto, a tech writer working with a developer can make an application far more usable and maintainable in the long run. So, we claim, that a kind of killer app development practice would be the shift of responsibility away from screen readers onto self-voicing applications, including operating systems, where development processes will be improved. We base our claims on personal experience developing a self-voicing podcatcher, @Podder, for partially sighted users using a speech channel of copying text to the clipboard to be read by external text-to-speech applications. Another self-voicing application is Kurzweil 1000 for scanning and document management, and employing the nicest spell checker around.

Can overcoming missing and muddled use cases conquer inaccessibility?

We have argued in “Are missing, muddled use cases the cause of web inaccessibility?” posting that the main culprit in web usability is not technical accessibility but the way use cases are represented, tangled, and obscured by links as well as graphics and widgets on web pages. A use case describes a sequence of actions performed to meet a specific goal, such as “register on a web site” or “archive e-mail messages”. Use cases not only lay out actions but also provide the rationale, the consequences, constraints, and error recovery procedures for interactions. Our claim is that software developers, both desktop and web application developers, force all users, sighted or blind, to infer the use cases from the page contents and layouts, often embellished with links, such as blog rolls, to enhance social interaction and increase search engine rankings. Reports such as those from the Web Insight project and the Nielsen Norman report “Beyond ALT text” describe in gory detail the frustrations and failures of visually impaired users struggling with their screen readers and magnifiers and braille displays to overcome the practice of poor use case representation as they try to keep up with sighted users in gaining information from and performing consumerism within the constellation of current web sites. While I certainly believe that web accessibility activists are important to removing barriers and biases, the larger improvement will come when web sites are designed and clearly presented to achieve their use cases, for the benefit of all those who gain from better web site usage. This is already occurring with re-engineering for mobile devices where failure to activate a use case or have available the appropriate use case is especially apparent, and, seemingly, not really that hard to achieve.

How will mobile devices improve accessibility?

Finally, what about the marvelous mobile devices such as the fully voiced, menu-driven Levelstar Icon and APH Braille Plus Mobile Manager? After 8 months of Icon addiction, I firmly believe that, cost aside, this form of computer is far superior to conventional Internet usage for the activities it supports, mainly e-mail, RSS management, browsing, and access to resources. for example, I can consume the news I want in about an hour from NY Times, Washington Post, Wall Street Journal, Arizona Republic, CNN, InsiderHigherEd, CNET, and a host of blogs. And that’s BEFORE getting up in the morning. No more waiting for web pages to load on a news web site, browsing through categories on information that don’t interest me, and bypassing advertisements. Additionally, I am surprised at how often I use the Icon’s “Mighty Mo” embedded browser by wireless rather than open up the laptop to bring up Firefox and fend off all my update anxious packages and firewall warnings. Yes, life with the Icon is “living big”. the Icon is mainly part of the trend toward phones and wireless devices, but just happens to be developed by people who know what visually impaired users need and want.

Maybe, somewhere out there is a wondrous software package that will dramatically boos the productivity and comfort of visually impaired computer users. With some assurance, we can recognize an upcoming generation of open source oriented developers seasoned by traditional assistive technology and adept at both project organization and current software tools. Funders and support organizations can look ahead to utilization of their innovations and improvements. But maybe the core problem is much harder, as we claim, a disconnect in “computational thinking” between software designers who have found their way through models and user-oriented analysis and those web designers stuck at the token and speechless GUI level of browsers and web pages. Empirical researchers on accessibility are starting to witness and understand the fragility of users caught between artifacts designed for sighted users and clumsy, superhuman emulating tools such as screen readers and magnifiers while the proper responsibility for accessibility falls on developers who have yet to appreciate the power of readily available speech channels along side graphical user interfaces.

What do others think? Is their a “killer app” for accessibility? Comment on this blog at, “As Your World Changes” blog or e-mail to

Web Inaccessibility — Are Missing, Muddle Use Cases the Culprit?

Web Inaccessibility — Are Missing, Muddle Use Cases the Culprit?

As I have been learning to traverse websites using the nvda screen reader (previous post) I try to formulate the principles of design and implementation that make this task more or less productive, as well as pleasurable. At the same time, I have been tutoring myself in the accessibility literature, mostly in the form of blogs and podcasts. This post recounts some of my frustrations, diagnoses possible remedies, and a sweeping conjecture about the root cause of much web inaccessibility and difficult usability.

As I improve my proficiency with the nvda screen reader and learn to navigate web sites by voice and keyboard, I am constantly amazed at how hard it can be to get where you want to go and avoid heading down the many, well, blind alleys. I am an Internet veteran: first email around 1976, worked with protocol pioneer Jon Postel, saw Mosaic in late 1992, had my first web page in 1993, set up my first domain name and website in 1995, and several websites since, plus writing search analysis software, Java applets used around the world for security training, and a podcatcher for partially sighted people like me. However, all too often, I find myself fumbling, stumbling, and cursing my way around websites, wondering why using a browser with a screen reader is so difficult, error prone, and exhausting. Is it the tools I am using? or my admitted status as self-trained beginner in the low vision world? ignorant of accessibility tricks and techniques? or maybe I expect the task to be easier than possible, for me or others?

To document my environment: Windows XP on tablet PCs, Mozilla Firefox browser used for over 3 years, TextAloud toolbar for reading and zooming on pages, nvda screen reader used for 2 months as discussed in previous post, responsive natural synthetic voices, pretty good bandwidth on home wireless and cable. My main browser interactions: h for heading to page sections; k to links; control F for quick find page search; tab among page items; up and down arrows through lines; page up up, down, home, and end to page boundaries; INS + down to read consecutively down a page; INS + BLANK to pass through typing into form fields; control K to start a search; control L to open a new site.

Here are a few situations, complaints, diagnoses, and remedies.

Booking a flight on USAir, fondly known in Arizona as America West. I cannot find the boxes to query for flight schedules then make a choice and book the flight. So I reluctantly call the 800 number, beg my way out of the $10 booking penalty, and hope for a good fare. The problem in software design terms is that USAIR has scrambled its use cases together on the first page, providing last minute specials, detours to frequent flier data, wonderful offers of cruises and vacations, and practically everything the airline does. On a good sight day, I can locate the depart/arrive boxes to start, but screenless. Like many commercial booking websites, I give a rating of “hopeless jumble of links” although the sites may still conform to the letter of accessibility rules.

Amazon has also seemed like another jumble of links: recommendations, my account, searches for all kinds of items, invitations to become a seller. But, thankfully, there is a link to a more accessible streamlined page I can actually use most of the time. It is ironic that the needs for mobile users to see small screens coincides with the needs of visually impaired users to traverse streamlined web pages. This allows me to get most of a pre-defined purchase completed, going into exploration and recommendation mode when I choose rather than as obstacles on the route to a purchase. I still need sighted help to get the coupon numbers copied onto the purchase page, but transaction appear less daunting now on Amazon. Actually, on return recently, the website appears to be undergoing a makeover from accessibility experts – kudos to them!

Hurrah!! it is so exhilarating to see a simple page show up, just like the early days of the web, before images, adsense, navigation bars, dynamic content, etc. So, here is a remedy when doing battle with a complex commercial site: Look for a “basic HTML”, “mobile friendly”, “mobile optimized” link and throw back to the early days of the web. Thanks to Allison Sheridan for urging me in this direction on her vision-friendly NoscillaCast podcast.

How about search sites? Well, google is pretty good at separating its search results with headings with intervening links to google alternatives, including the extremely valuable “view as HTML” that avoids a cycle of save, import, export as text, and listen rather than open the usually unneeded Microsoft Word and Adobe PDF. On the other hand, the tagged and search-based gmail is a tangled overlay of use cases. For example, archiving messages by a filter requiring several steps down to a filter label, over to a select all link click, combo pull down to Archive list item, and return to Inbox. In single step mode,, one can check the box for conversations the find the archive button. Or there are keyboard shortcuts that my mind simply boggles at learning. At least reading gmail is enabled by a pop3 account on my Icon or, soon to be, fully voiced Mozilla Thunderbird. Google offers a separate search that weights accessibility into its search results, but I have not used it sufficiently to comment.

Blog readability varies a lot, but at least there is a common structure: entries with associated reply and comment fields; archives; blogrolls of links; and assorted meta data and added pages. The clincher is choice of template to place navigation bars relative to blog entries — right and below being best for screen readers and spoken RSS clients. While not easy, the wordpress dashboard is usable through a combination of good structure and parsimonious informative link labels.

Government Web Sites often, while conform ant with the so-called 508 mandate, follow a recognizable organizational or legislative hierarchy, sometimes with a touch of hilarity. I’m familiar with the NSF Fastlane proposal management system, which has changed little in the past 5 years except for an accretion of bureaucratic guano. It took me 17 tabs to get to the login box on one page, covering links about travel, registration, policies here, manuals there when the sole purpose most users would be on this page was to enter username then password. Later I found myself scrolling over a large block of text to the worksheet, a rendition of workload requirements that nobody in their right mind would read except for a hapless blind person who got stuck there. My complaints to a government representative were duly noted and agreed with but it will take a very fresh perspective to turn a bureaucratic haystack into a really usable website, well beyond the purview of accessibility standards that may simply divert attention to the wrong details.

I was highly impressed recently on the website when a link came up for screen readers. Following that path, I soon ran into the hilariously dumb “Click here” link text that should be a red flag for any accessibility analysis clickhere for what? And there was a sequence of “click here” on a page expressly designed for screen readers! Geez, where are the accessibility police?

Well, that’s enough complains, what does the literature of accessibility tell us? First, there are the common sense guidelines, see links below, that mention the sensible ordering, link text, graphic ALT tags, use of headings to reveal page structure. Any trip into the standards literature shows how complex the language and tradeoffs are, when compiled by a group of experts trying to reach a consensus — not an easy read for anybody, and a good excuse for routine web designers to avoid thinking about accessibility. The standout book for me is “Constructing Accessible Websites” which tours the landscape of HTML and CSS as well as the legal issues, e.g. can that routine web designer be held accountable for violating ADA laws?

Blogs such as “A List Apart”, WebAxe, WebAim, etc. often delve into highly technical issues of web accessibility at a feature and technology level. The tradeoffs of writing a web page one way or another are often poorly understood and tricky to articulate so the expense of apaplying a particular rule can be hard to justify. Indeed, my technical background combined with my accessibility needs leads me to commiserate with people who must deal with accessibility, especially late in website design or even later in mintenance, violating the software process rule that cost escalates with delay in addressing a solid requirement.

I have been confusing two terms here, “accessibility” and “usability”, with the latter my main concern. Accessibility is more technical in stipulating that the system stack of hardware, operating system, applications, and screen display provide sufficient and correct information about the screen data state and events to screen readers to interpret and pass onto uers. This architecture is historical and, I believe, wrong to its core now that we have a “speech channel” that could throw the responsibility for interpretation and amplification of data provided to bypass or supplement the screen reader ,, but that’s a future posting. Usability refers to the bottom line of whether users can complete the tasks at hand. Inaccessible features here and there may be barriers to usability but issues of separation of content and presentation, well-planned navigation, and display of the right stuff at the right time most determine usability.

For this Vision Loser, there is an internal batter reading of energy consumed by tasks, enabling me t to predict impossible tasks and schedule smaller chunks of work that can be completed. We have noted in our post on “Extreme Voting” that voting tasks fall in the range of Olympic events which must be completed under severe time constraints with no prior training or practice, complicated further by long ballots. To sighted people open to a comparable challenge: use a talking ATM to withdraw $100 in less than 1 minute.

A few conclusions are:

  • The book “Constructing Web Accessibility” validates my navigation complaints as common and often cured by “link to content”, “jump to sidebar”, modest sized navigation bars, supers mart screen readers able to recognize chunks of HTML as non-content to bypass, and and avoiding the pernicious dumb “click here” or “learn more” link. These are sign posts of attention of web site designers toward accessibility and techniques to improve my browsing practice.
  • Indeed, I am not fully empowered by my chosen screen reader to jump comfortably to all parts of a pages I will wait for the next version, partially developed under a Mozilla grant, to determine whether this youthful product is remiss and watch carefully for the productivity improvements noted above. Meantime, I can live with excess links as long as I know where I am situated on a page, e.g. by a “heading tour”.
  • I just can’t help but reverse engineer each transactional website into its use cases and mentally Write an introduction I wish were available as a spoken site overview.
  • The trend toward mobile pages offers a practical remedy for working on many websites, with hope for momentum to alter web design.

So, what is the big deal with “use cases”? The sweeping conclusion.

The concept is quite simple: a system’s design starts, in part, from a suite of named paths through the system’s eventual operations interleaved with those of users and other systems. Each use case has a precondition for its proper execution, a post condition stating the changes and outputs, and considerations of errors and options. In practice, a use case analysis can take several weeks and result in multiple pages of structured text and graphics, sometimes produced by CASE computer-assisted software engineering tools. This kind of stuff is taught presently in software engineering and object-oriented design analysis courses.

My complaint is that these use cases, whether explicit or not, are then mapped into a few web pages with forms, combo boxes, and text labels. The situation is close to what we called in the 1970s “spaghetti code” where control flow was woven through small sections of code because the state of programming languages did not sufficiently support modularity or the world view of object orientation. HTML is the assembly language that is unfortunately available to thousands of web designers not educated in the more advanced methodology and tool base that systematized programming to some extent.

The sighted person has an intuitive grasp of what each form needs and the physical agility to complete it and to detect and correct mistakes. The visually impaired person must somehow parse how the use cases, find the appropriate forms, meet the unidentified preconditions, find error message and fault locations, avoid cancel buttons, and complete the task before a time-out, wireless failure, or automatic PC update invalidates minutes, or hours, of tedious work.

Note again how nicely the “mobile revolution” can cooperate with accessibility. A site developer must identify the most important use cases to place on a mobile-friendly page, strip off ads and special offers, put the function forms prominent, and not clutter the page with navigation. That busy traveler needing to order a gadget without recommendation use cases, frequent purchaser signups, and the latest added options’ — and so does the visually impaired user. Separate and save the recommendations, special offer shopping, and account management until the transaction is completed or for idle browsing moments.

Looking back at our examples: a flight schedule lookup should not be cluttered by cruise offers; a log-on to enter a review system should not be over-run with travel instructions; a workload policy is worth no more than a link off a worksheet page, at worst at the bottom; navigation bars aren’t relevant to most use cases; and a mail archive is a lot different than an email lookup. Accessibility writings warn of the difficulties presented by mixing presentation with structured content, e.g. omitting headings. An insidious practice seems to be the desire to make all use cases available on a single page. This is a weird form of optimization I wish someone could explain to me. Is this optimization a root cause of broken rules of accessibility, poor structure, an insurmountable challenge to screen readers, and a constant pain to visually impaired users?

Not surprisingly, a search on terms “use cases and assistive technology” or “use cases web page accessibility” shows some interest in this topic in the w3c and usability communities. My epiphany for my own learning and continued improvement in web skills is that it helps to construct a mental map of the use cases and how they are implemented in the navigation and interaction items of a website, whether on a single page or across a site. My wish is that web page designers would present an overview of their web site in use case terms. In the longer term, it would be great to have multiple presentations, such as the trend toward mobile-friendly pages, where the use cases are sufficiently separated into separate pages that the mental load of intuiting and remembering the use cases becomes less critical to successful use of their sites.

Recently, I ran across JumpChart, a web page design tool that supports what usability people call a wire frame. This tool is exactly the place to interject both accessibility concerns and mechanisms for supporting accessibility.

Wow, is there a lot of substance to this topic. I hope soon to find counter-example websites to the troubles I attribute to missing and muddled use cases, as well as highly accessible pages in the technical and usability sense. Finally, my own mea culpa for all the stupid stuff I have dropped onto websites and made usability harder — I am working to correct my bad style. I haven’t addressed the Target lawsuit or capcha or other biases and so much more is known about hacks and techniques for accessibility. See our podcast library for hours of informative listening.


  1. Guidelines for 508 government website mandate
  2. Recommendations for accessibility from MIT
  3. Amazon entry and reviews of “Constructing Accessible Website” book and “Constructing accessible websites also available from Bookshare
  4. accessibility consulting and resources from Jim Thatcher
  5. Webaxe accessibility tips and podcast
  6. <a href=”;?Wikipedia article on “use cases”
  7. ` WebAIM blog roundup of blogs on accessibility

  8. JumpChart web design service
  9. nvda, nonVisual Desktop Access free, open source screen reader
  10. podcast library on “web accessibility”, collected by @Podder podcatcher

Mouse Hacks, Magnifiers, and Being Your Own System Integrator

In this post, we look for ways to reduce the costs of our computing environment as we deal with vision loss. Magnifiers are helpful, sometimes essential, and, we show, can be very low-cost with additional benefits.

Assistive Technology (abbreviated AT) software comes in several cost categories: built-in, $0, $50, $500, and $1000. The “big AT” vendors sell to individuals, of course, but the main market is the IT and A.D.A. support organizations of government agencies and employers, i.e. the “budgets”. I claim that an independent Vision Loser can save by becoming a System Integrator of sorts avoiding not only costs of acquiring “Big AT”, but also reducing complexity of installation, maintenance, and training.

Here’s a little case study in System Integration, First, some caveats: I am neither a trained rehab/AT specialist nor an experienced System Integrator. But I did go to conference with these types and have assembled a library of podcasts and web articles with excellent advice.

What we are calling a “System Integrator” is someone who looks at how components work individually and composes a new “system” where the components work together to achieve a goal. With the uncertainty of progressive vision loss, a worthy goal is frequently a kind of testbed to experiment with techniques that compensate for vision deficiencies and offer a measure of comfortable use. Experimental results may lead to identification of a suitable product or provide experience for evaluating more costly alternatives.

Here’s our goal: low-cost magnification capabilities for a Windows XP computing system. The underlying problem is for this Vision Loser to have available screen magnification when needed to complement self-voicing and screen reading software (a future post). I really want to know both what is (1) necessary and (2) sufficient to meet my vision needs, keeping mind that needs will change as vision changes. Change is as much daily, even hourly, variation as slower deterioration.

Well, how about that! Microsoft accessibility software includes a simple stationary magnifier with several levels of magnification and inversion of screen colors. Stationary means it doesn’t follow the mouse and it can be docked at one of the borders so it doesn’t move around. Indeed, I found I liked a stationary magnifier set to level 2, inverted, and docked at the top. The down-side is vertigo from the magnifier tracking the mouse. So, Only time and trial would show its sufficiency.

Enter the “{mouse”. and yes, we were talking about magnifiers, not pointers, or vermin! On a trip to a computer store, I decided to pick up a new wrist rest and a more comfortable mouse. By sheer luck, my niece shopper assistant pointed out a mouse with a magnifier. At home, I discovered that this little guy really is useful. It provides a “tracking” magnifier to complement the stationary Windows lens, again within levels of magnification and resize of the tracking box. Now, with a flick of an extra side button on the mouse, up came a magnifier aimed at the text I want to read. The product model is called a Microsoft Laser Mouse 5000, but these names and model numbers may have changed.

But, wait, what about the extra button capabilities that come with the mouse. Only the right side button, an extra sliver, is being used, to pop up the tracking magnifier. Wow, I have these other tools that read to me when I copy text to the clipboard (see previous post). I wonder if I can link these two. Indeed, the left side mouse button can be assigned to Select All and the Wheel button to Copy. Now with two clicks, I can hear a window of text. Cool! This save fumbling around the keyboard for Control-A then Control-C or a couple of trips down a context menu.

This is what computing folk call a “hack”, a clever way to get a job done, maybe not obvious or elegant but definitely effective. Indeed” OReilly Press has raised “hack” to a publishing genre, with piles of books that collect, explain, and propagate hacks for Amazon, Google, podcasting, even mental productivity.

There are always trade-offs in any system design. The first is that a solution only works if you remember to use it! That use must become part of your reflex repertoire But then you’re in trouble on a different computing system at a friend’s office or on a consulting gig. I forgot my mouse on a recent trip and walked over to a Staples to get a replacement, a smaller notebook mouse with a single side button magnifier. It worked right out of the box, but getting the thing released from its hard plastic covering required 2 hotel clerks and some dangerous instruments. Then, I really noticed the loss of select-copy functionality as I struggled under fluorescent lights and a nasty wireless security system. Further, to make my hack work, the Windows security system had to permit copy to clipboard, which many IT departments like to over-ride.

What if I want or need more magnification? Software like ZoomText is widely used (I hear from podcasts) and is designed especially for partially sighted people. A trial use early in my vision loss showed how many ways graphics could be adjusted to achieve magnification and contrast effects, with the primary benefit crisper text at higher levels of magnification Indeed, vision is so complicated – is it color, contrast, glare, font, or other factors that are most crippling to a particular Vision Loser? And, my vision changes so much, with lighting conditions, time of day, cumulative exposure, and who knows what other factors. In any case, the $500+ price tag was out of my budget at the time of trial.

What is the System Integration lesson? In “computational thinking” terms, we look for abstract interfaces of components, primarily their inputs and outputs. We don’t worry about the buttons or the user interface or menus but focus on the generic capability. In this example, the system clipboard is a (hidden) input to TextAloud (or similar tool that monitors the clipboard) and our MS Laser Mouse has a (hidden) output to copy selected text to the clipboard. Well, duh, the clipboard pervades Windows applications, but now we have endowed it with text-to-speech reading capabilities. We’ve wrapped a different way of thinking about the united capabilities of two separate components – a text reader application and a mouse.

When you put yourself in System Integrator mode, you ask: what’s my inventory of components? what are their abstract interfaces? how can I connect these applications together? How much complexity is added to my system by now having inter-linked components, e.g. when one is upgraded? What forms of training are now required, including getting used to, learning the foibles of, and gaining reflex control over the new capability? How do my solutions compare with each other and what are the trade-offs? Is there a show-stopper against or in favor of a particular solution?

One of the most serious lessons of the Software Engineering field, where I formerly taught, is the importance of getting the requirements right early on. That usually is not possible in our Vision Loser world, but rather we need to set up an experimental testbed where we can try out different ways of compensating for vision loss. Necessary and sufficient are always concerns, e.g. an expensive solution may be sufficient but not necessary while a low-cost solution may be necessary for some uses but insufficient for others.

Readers of this posting might be wondering: why not ask an expert? Well, I don’t have one handy, have never had computer rehab support from an employer or agency, and, frankly, have already had some unsatisfactory experiences with consumer low vision businesses. But really the experts are out there, telling me much good advice on podcasts and in accessibility publications. Thanks to them.

helpful podcasts and articles:

Access World comparison of magnification products Search (upper corner) for “Zoomtext, MAGIC, magnifiers”

Barrier-Free IT Tips and Tricks podcast on the Windows Accessibility Wizard

Literacy Questions for Magnification, Karen McCall from Carlin Communications
(link to be found)

OReilly “Hacks” Series

Microsoft Laser Mouse search for “Microsoft Laser Mouse” and “on screen magnifiers”