Wednesday, July 16, 2014

Code Reader versus Screen Reader

I came upon an interesting article by Tracy Mitrano whose intent was to describe the evolution of the definition of accessibility through laws and court cases as technology changes, including its place in cloud computing. Towards the middle of the article, Tracy hits on something that I think we've all been explaining incorrectly, and it's probably why our users don't understand why we say certain issues are inaccessible.

What is a screen reader? When the average visual person reads those two words, it seems to mean that what you see on your computer monitor is what this software program is reading to a blind user. This is more the goal than the actual service provided.

Yes, we'd love for screen readers to provide all the information we place on the web pages to the blind. Seems like a fair deal, right? But how do you do that? And what are they actually getting? Keep in mind, they are listening to a textual description of the content, not seeing a visual interpretation.The textual description blind users receive is based on the code that makes up the page  of all its content and functionality.

For example, we have a piece of code that basically says, "Computer, please put this image file on the web page." A picture now appears on the page.

"Computer, please put that image on the left side of the page." The picture appears on the left side of the page.

"Computer, please resize the image proportionally to be 300 pixels wide." The picture appears on the left side of the page proportionally resized to 300 pixel width.

We don't say that much when we program, since that would be a lot of typing, but you get the idea.

Most of the "code" mentioned above only speaks to visual characteristics of the image on the page. No blind user is going to be concerned what size the image is nor will they care which part of the page it is located on. Right now, they still don't even know what the image "looks" like. That's where alternative text comes along.

When we ask the computer to place an image on a page, we have code for alternative text, so screen readers can tell blind users what an image "looks" like at that place on the page.

"Computer, please provide alternative text for this image: Baby laughing at a playful kitten tied up in yarn." Though you just read it, you have a visual image already in your head. That is what blind users "see" in their own way.

Instead of reading what the screen shows, our computers are reading what the code provides. That means that only when we properly code our web pages do blind users receive a similar experience to that of a visual user looking at a computer screen.

What do Screen Readers read?

Code. First and foremost, you must understand that what you see visually is an interpretation of code by a browser that you are using (and if you've opened a website in multiple browsers, you'll note they show content a little differently from each other). A screen reader reads the code behind all the fancy visual effects of the page from top to bottom. No matter how it is positioned on the page, for the most part* screen readers provide code on a first-come, first-read basis.

*This only changes if there are real-time interactions, like those on a social media account where a notification pops up telling the user they might want to take immediate action.


A screen reader will read everything, and I mean everything. If every web page on a website has long navigation at the top of the code on their page, that blind user will have to listen to it every single time.

This is different for visual users, since we can gather a lot of information by scanning our screen. We quickly move to the area of the page we want to focus on with our eyes.

Screen readers provide similar scanning functionality through tools we visual users like to call shortcuts. They are the primary way blind people use the website, so web maintainers are recommended to accommodate them.

The good news is that if we use web page semantics properly, we benefit blind and visual users at the same time.


Using Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6 on your website correctly can help all users scan, or skim, your web page easily for content. Since many users don't like to read, or they are in a bit of a rush, skimming is a common practice. Using these headings sets off content for visual users as well as blind users.

Blind users have a shortcut that lists out all the headings on a page. They can perceive importance and relevance of information quickly by scanning this list.

Screen readers introduce headings, along with their heading level, and read the text for that heading.
  • DO use headings to separate chunks of content.
  • DO use headings hierarchically (i.e., first Heading 1, then Heading 2 without skipping around).
  • DO NOT use headings to visually increase the size of text.


Screen readers have a shortcut that lists all the links on a web page. That means the links are pulled entirely out of the context of the page.

They introduce the link and then read exactly what is in the text of the link or the alternative text on an image that is a link, not the titles on either one.
  • DO state where the link is going via a call-to-action or other direct text (i.e., "Apply Now to Hug Kittens!", "Kitten Hugging Application Form", "About the Kitten Hugging Program").
  • DO NOT use "here", "click here", "more", or other text that does not provide relevant information about the link.
  • DO NOT use the web address, or URL, as for the link's text.


Unless an image has alternative text, blind users completely miss out on the important information or context it provides a visual user. Rarely should any images be considered "decorative," and given our need to reduce load time on the Tarleton website for users with slow connection speeds, we reserve the right to remove any unnecessary images including those without alternative text from Tarleton web pages.

Screen readers introduce images and then read the alternative text for those images. If the alternative text is too long (over 140 characters), web maintainers should provide an alternative means to describing an image which Web Services can assist on.
  • DO keep descriptions as simple and concise as possible without losing the action, mood, and/or tone that should be interpreted from the use of the image.
  • DO keep alternative text descriptions of logos simple (i.e., "Tarleton State University - Member of The Texas A&M University System", "Texas A&M University", "Kitten Huggers - No Reason, Just Because").
  • DO NOT create text-heavy images that cannot meet the alternative text character limit (140 characters) and generally avoid them if possible.
  • DO NOT include introductory words like "Image of", "Symbol of", "Picture of" to inform blind users they are at an image, since the screen reader already informs them.


Keep your content meaningful. Screen readers allow blind users to skim paragraphs by reading only a few words at the beginning of the paragraph before moving on to the next one.

Screen readers pause for punctuation as well as for the end of the paragraph.

Some screen readers read words in all uppercase word as initialisms (i.e., CIA, FBI, TGIF, ICYMI, BTW), so it can become aggravating to hear each letter sounded out. Others read all uppercase sentences as shouting which is considered inappropriate internet demeanor.

Bold and italics are interpreted as important content or content with emphasis. When entire paragraphs are marked up as bold or italics, interpreting the important pieces becomes impossible.

Screen readers cannot discern the difference between extra characters and punctuation for aesthetics or setting off important information. They will read each punctuation symbol or space individually which will cause confusion.
  • DO create meaningful content in small chunks.
  • DO use proper grammar and punctuation.
  • DO use all uppercase letters for acronyms but avoid them anywhere else that may deem it shouting.
  • DO NOT bold or italicize entire paragraphs.
  • DO NOT add spaces or other characters for aesthetics.
  • DO NOT add extra punctuation (i.e., "!!!", "**", "------", "---->") to denote importance or emphasis.

Lists (Unordered and Ordered, or Bulleted and Unbulleted)

Lists are great for setting off chunks of content and improve readability on web pages. Blind users take advantage of them in a way visual users typically don't: screen readers give blind users a head's up on how many list items are in each list before reading them off.
  • DO use lists for content that can be appropriately set off in small chunks for speed reading.
  • DO use lists for sets of links instead of paragraphs.
  • DO NOT use lists for content that is more readable as a table.


Table layouts are notorious for being inaccessible as screen readers cannot determine the direction their content should be read appropriately. Tables should only be used for tabular data.

Screen readers go into a table reading mode that excludes content not typically a part of a table.

In table mode, screen readers will inform blind users of how many rows and columns are in a table, similar to the functionality of viewing a list.

In order to interpret direction and location in a table, screen readers turn to table headers for the meaning of table cells and the scope of cells the table headers define or support. These table headers are introduced before the contents of each cell are described.

Table headers are often misconstrued as bold text or Heading (Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6) text in a table cell. The reason for this confusion is because semantics do not carry over correctly from Microsoft Office documents to web pages.
  • DO make table header cells of the "cell type" Table Header for proper semantics.
  • DO request assistance from Web Services to clean tables copied/pasted from other documents.
  • DO NOT create table header cells using bold text or Heading (Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, and Heading 6) text.
  • DO NOT create tables specifically for layout purposes.

Other Semantics

Since Web Services maintains the code for much of the other content, I won't go into detail on forms or buttons. Screen readers do have a form reader mode, similar to the table mode. Forms are more complex, given the many form field types and the need to provide labels and instructions for each one in different manners. If you ever need a form, please contact Web Services to assist you.

Examples of Screen Readers in Use