Thursday, July 17, 2014

Other universities in the media

(Photo from nicolasconnault)
Web Services' staff is tasked with evaluating Tarleton's web pages and vendor-contracted web pages/technology for accessibility, copyright, and security issues. This is a tedious yet necessary responsibility that the university is required by law to perform. As we have learned more about these federal requirements, we have over time made our evaluations more stringent.

We have observed the ramifications of what happens when a university ignores its obligation to abide Section 508/TAC 206, U.S. Copyright Law, and TAC 202. We do not want similar actions taken against Tarleton, which is why we adamantly check our websites, software, and other technology for compliance.

Doing these evaluations does take some time. Sometimes I would rather be working on web graphics or designing web layouts. However, if we do not take the time to evaluate, a reprimand (or worse) is just inevitable.

The following are examples of universities who have been reprimanded/sued/reported for not complying with accessibility requirements. I think you will be surprised!
Here is an example of a situation where the owner of non-popular blog was sued for copyright infringement on one image. And no, universities can not claim "fair use" on images posted on it's public website - they must follow the same rules.
Due diligence is the key here. And even though these are requirements by law, shouldn't we at least feel morally obligated to provide equal rights to services and prevent theft? I think so!


    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


    Monday, June 30, 2014

    End the Bloodletting in Digital Visibility

    Over the decade I've been working in web design, I've come across multiple complaints from staff telling me a student or parent called about being unable to find something on their webpage. I come over to their office, so we can look at their webpage together, and we notice that the content is really there, so the next question is typically: how do we get people to notice this information?

    I've seen a very common "knee-jerk" reaction to this issue that reminds me of the days of bloodletting. No, I'm not old enough to remember it firsthand, but if you will recall from your history books, doctors used to believe that the reason people were sick was because something bad was in their blood. If they removed the infected blood from a person's body, that would cure them of their ills.

    Now, it's true, you likely do have a lot of bad stuff running through your blood when you are sick, but what else is in running through your veins at the same time? Good blood cells that are fighting off the bad bacteria and viruses. Those doctors didn't know that at the time, so they would continue to remove good and bad blood from their patients' bodies. Did that help? Sometimes, but they likely also killed many patients in the process. It was an inefficient solution.

    Archaic Solution for Digital Visibility

    I often see similar solutions when it comes to making content more visible to users of websites. Web maintainers are constantly told to do the following to make content more visible:
    This is really important information. I mean, important. Like, come on now. You need to read this!
      Okay, well, that didn't work. Let's try:
      This is really important information. I mean, important. LIKE, COME ON NOW. You need to read this! 
        No, still didn't work. Let's try:
        ***This is really important information. I mean, important. LIKE, COME ON NOW. You need to read this!***
          On occasion, this seems to cure the problem, right? You seem to be getting fewer questions about it which also seems to prove that your technique worked. As you can see from the above usage of bold, italics, underline, color, font size, and extra characters, you may have solved the visibility problem of one portion of your content, but you may have created potentially many others.

          What else might be happening? Users are now calling that they can't find some other content that you and I both know is on the same page as the content we just fixed.

          Why is this Not the Solution?

          What common purpose do all these techniques shown in the above examples actually have on your page? All of the above techniques are merely aesthetic modifications. Granted, when we think about aesthetics, we think about what we see with our eyes, visual cues to direct our brains to pay attention to specific content. However, if there are multiple regions of content applying these techniques, our brains can only focus on the content temporarily, as they notice another region and then another, and may not record this information into memory.

          Your content is going through a visibility war. Each piece is now in competition with the next piece of content. From an accessibility point of view, this is very bad for users with permanent or temporary mental disabilities (see Simulations of Mental Disabilities), such as attention deficit disorder or TV combined with a screaming child. And considering these modifications are for people who can see, what purpose does font size or color have for catching a blind person's attention?

          The Modern Solution for Digital Visibility

          This isn't a design issue, this is a content issue. That is, you need to rethink how you write your content before resolving that the issue is aesthetic. Here are some tips for making your content more visible.

          Page Flow

          Your users should be able to easily scan your page top-down for information. If they pop around on the page, they will lose focus.
          1. Be clear and concise, and keep your paragraphs short.
          2. Turn your content into consumable (small) chunks of information.
          3. Use tables and lists over paragraphs to make content easier to understand.
          4. Separate your consumable content with short headings for easy scanning and comprehension.
          5. Keep It Simple


          Your users need to be able to understand what you are saying. This goes beyond spelling and grammar.
          1. If your audience for this page is external, avoid using jargon that external audiences will not understand.
          2. If jargon is needed, define jargon after you have led users to your content with commonly understood terms.
          3. When speaking to a general audience (i.e., parents and potential students), make sure your content is readable at a sixth grade level.
          4. Summarize complex content first before introducing such content, if it is required on your page.

          Content For Your Users

          Think about who is reading your content, their personas. Each page your create must serve a purpose for your target audience(s).
          1. Change the purpose of content from what you want to see on the page to what your audience wants to see.
          2. Cut any content that does not serve a valuable purpose, that isn't benefits or value driven, or a call to action for your audience.
          3. Organize your content based on the importance of the information to your audience. 
          4. Write to your audience instead of using third person, so your audience can connect with your message.
          5. Keep the tone of your message upbeat, and rephrase your message in a way that makes "bad" news, or a negative call to action, look like "good" news, or a positive call to action.

          More Information

          We can't put everything and the kitchen sink in one blog post (similar to the issue with overloading web pages with content), or you would stop reading! However, if you need to reference more information, put it at the bottom of your page, so when your users do have the time to read, they will come back here and check out these valuable links.

          Simulations of Mental Disabilities

          These videos are simulations of how the environment can affect a person with a mental disability. A physical environment is no different from a virtual environment as both have sights and sounds. Web designers often talk about a layout being "too busy." Think about what you see and hear in these videos and how this may affect layout of content on a web page.

          Caution: These may trigger reactions for those with autism, Aspergers and other mental disabilities.

          Monday, June 23, 2014

          Searching for a search


          In the beginning...there was responsive design for the website. It was good, but there had to be a better way to search on the website. So the search began for a better search. It had to be light so phones could access it, and it had to be easy to use so users wouldn't have to waste too much time keying in their search request.

          The Search

          Like many other colleges and universities, Tarleton utilized Google's Custom Search Engine to search our website. As we saw from other universities using the Google search, results would always appear on a generic results page, however we needed more control over the results because of issues our users had from this search engine:
          • Results would rank our departmental pages inaccurately
          • Results for the existing online phone directory couldn't be combined with the Google results
          We needed more information and less information all at the same time. We wanted our search to provide better results for what users requested as well as more options to fine-tune their request results.

          We found that Facebook's search function was different. It was full-featured, and at the same time unobtrusive and minimalist. We liked the idea of providing categories (i.e., search the web, search the phone directory, search the website directory) for fine-tuning search results, and we could add more categories as needed (i.e., search the press releases). Web Services staff all agreed that the Facebook search style was the direction we needed to go due to its flexibility.


          Caution: Technical jargon ahead. 

          We had some feeds we could implement immediately our search, so in order to make them better for phones and just easier to use, I rewrote them to spit out JSON, which is an easier feed to manipulate (items being requested were just plain raw datum) and style for our use (no need to work around Google's styles to make the content appear seamlessly as part of the Tarleton website user interface). I also made use of AJAX, so the page would not need to be refreshed or open a new page which saves mobile phones from wasting data. In a world where a phone is taxed on how much data it uses, every kilobyte counts.

          As of this post we have:
          • People and Departments
          • Website Directory (formerly the A-Z Directory)
          • Google
          • News
          People and Departments is our updated phone and email directory. We wanted the results to be more accessible from a mobile phone, since smart phones can make calls off numbers displayed on web browsers. Also our desk phones connected to our desktop computers (and Cisco Jabber) can make use of the calling feature just by clicking the telephone icon.

          Website Directory (A-Z Directory) was pretty straight forward. Cascade Server (our Content Management System) publishes an XML file that one of my search scripts parses for absolute matches or keyword alternatives. Karole cooked it up to be easy to modify with keywords that should be connected to each website or webpage for quicker, more accurate search results.

          Google was a little tricky. The API Google provides for integrating Google search results on another website generally only allows for a limited number of results. To retrieve a longer list of results, you have to submit a request for the next set of results. That doesn't fly with what we were trying to accomplish in our seamless integration. In the background, when the user selects the 'More' button, a script runs loops to collect 100 searches. If Google runs out of results (which it won't), it stops the loop. In either case, it returns a JSON file with the results. The Google search results are the same results you see if you search directly on the Google Search website.

          News pulls its data from our press releases maintained by Media Relations. It just searches for anything with the search criteria and spits it back. We already had an implementation based on JSON and AJAX that use for the news stories on the front page, so it was very easy to just request news stories with a search term.

          Potential Future Projects

          We have thrown around the idea of adding degree program searching, locations on campus, and specific keyword translations based on analytics (e.g., finding a department whose name has changed).


          If you would like to provide feedback to us about the new search, such as ways to improve, just submit your feedback to our online form

          Keep calm and search on.


          Tuesday, May 27, 2014

          Hiring students for making web page updates

          It is very common for departments to hire students to make web page updates for their areas – and we support that! We recommend that if you are hiring a student worker/technician/intern for this purpose that you consult Web Services before making the hire.
          • We can help you determine how much workforce you need to work on your website(s) – do you need one or two students, or do we have office resources we can provide to you as well?
          • We can offer advice on what qualities to look for in a student for this type of position. They should be technologically proficient and have good grammar skills, among other things.
          • We will be required to train the student to use Cascade Server (our content management system) for updating your pages before they receive access to the system, and your student may need ongoing training as well.

          If you can involve us at the beginning of the process, we will do what we can to advise you along the way. Thanks so much!


          Wednesday, May 21, 2014

          Sharing Your Story

          I had the privilege of sitting in on the taping of our most recent Faculty Unscripted video with Dr. Joanna Shaw.  While I found the technical nature of videography to be interesting, Dr. Shaw's stories of family ties to Tarleton, her passion for students, and classroom interactions, really captured my attention.  Maybe it was the dark room or her kind voice, either way I was taken.  I found her stories to be authentic and full of detail.

          "Share Your Story" graphic with Dr. Joanna Shaw during filming

          Dr. Shaw has a real passion for her students and it shows.  Students are her favorite part of the job "because I meet students I would have never ran across at any other path in my life". She strives to make a connection with students by asking questions like, "What is best thing that's happened to you since we last met", prompting students to share their own stories.

          As I reflect on Dr. Shaw's video, I am reminded of an article I read in Entrepreneur Magazine called "Why Leaders Are Great Storytellers".  This article, while lengthy, talks about the fact that stories do not need to be complex to be effective, nor do you have to have some great power to tell a story.  It is all about helping others connect.  If someone can see the impact and the emotion in your story, they are more likely to connect.  As Dr. Shaw says, "these are the things that make us as humans unique".  So I would encourage you all to share your stories, and share what makes you unique.  Better yet, share your story and connection to our University because you are what makes Tarleton unique!

          Are you willing to make a connection?
          Do you have a story to tell?

          We are always looking for story tellers and would love to hear yours!


          Friday, May 16, 2014

          50 Shades of Universal Design

          One of the things I love about going to Knowbility's annual John Slatin AccessU conference is that I always learn something new that I never expected. I'll never forget my first conference when my instructor asked the class the rhetorical question, "So none of you use tables for your layouts anymore, right?"

          In reality, I wasn't the only one who wasn't doing it right. And while not knowing was a little embarrassing, I realized that we are all having to learn and adapt to changes in technology that we don't realize exist.

          Technology changes constantly. There was a time when wheelchairs, screen readers, and eyeball tracking cameras didn't exist. As each technological device comes into the world, we must learn not only how to use it but how to use it correctly.

          The AccessU workshop that stood out for me this year was the first one that ever had us walk outside our classrooms (in the rain) and actually ponder universal design from a physical point of view: Adopting a Universal Design Approach for Accessible User Experience, presented by David Sloan.

          After all, our website is our digital, or virtual, "storefront." When our students come onto campus, they are on our physical "storefront," and both "storefronts" are required by law to be accessible. (See Section II: Overview of Requirements on the ADA Title III Highlights page of the Americans with Disabilities Act website)

          Let's go back to one of our favorite inventions that we often relate to accessibility: the ramp. We all know that people in wheelchairs use ramps to enter buildings or access parts of a campus that may be on multiple levels of terrain. The ramp is an accommodation for a disability that would otherwise become a barrier for wheelchair users as they would have no way to access the buildings. Based on ADA, barriers to access for disabled people are now known as discrimination. They are an infringement on the civil rights of disabled people.

          St. Edwards University is aware of this potential barrier, and throughout their campus, they have provided the accommodation of a ramp. Solves all the problems, right?

          Well, not so much:
          1. Where is the ramp located in relation to the building? Where is it located in relation to the normal means of entering the building? Is there an undue burden made for wheelchair users? 
          2. Is the ramp easily accessible on its own? Does it allow a wheelchair to safely turn on the landing platforms getting on or off the ramp? Is it too steep? Are there barriers to prevent a wheelchair from falling off the ramp?
          (For the technical standards architects must review, see 405 Ramps in Chapter 4: Accessible Routes of the ADA standards website.)

          A universal design should give all users an equitable experience. This equitable experience includes treating able and disabled people equally, without segregating or stigmatizing any group. It also includes protecting them, ensuring their safety, security, and privacy in equal ways.

          These are examples of how wheelchair users can become segregated or stigmatized or have their safety compromised:
          • The door with the staircase is on the nicely decorated front of the building while the ramp is on the opposite side of the building where all the trash bins are located.
          • The ramp is only accessible to a wheelchair after you traverse a complicated sidewalk path going around the building.
          • A sign next to the ramp says, "Wheelchair Users Must Use this Ramp."
          Would you feel you were being treated equally if you had to go around the back in order to access the building? Or how about having to wheel your chair an extremely long distance to get to the building? Would you feel comfortable about going behind the building, especially where all the smelly trash bins are located? What about signs that tell you who can use various products? Remind you of any civil rights moments in history? These experiences are obviously not equal.

          What does this all mean from a digital standpoint? Our websites? Our emails? Our social media? Our telephones and other information technology and communications devices?

          As we continue to traverse both physical and virtual design, we find that the same standards apply. I'm not actually referring to the requirement to follow ramp standards on social media, since there are no ramps there. I'm referring to providing accessibility from a universal design approach as David Sloan presented.

          Instead of wheelchairs, paralyzed people use various assistive technology (AT) including that eyeball tracking camera I mentioned earlier that helps them move their mouse cursor around on the screen. Others have control over at least one hand that can push buttons on a keyboard but not a mouse because their muscles are not so coordinated.

          Instead of walking sticks, blind people use various AT including screen readers to tell them what is on their screen. Others (maybe the same people depending on the loud activity around them or the need for silence) use refreshable Braille displays.

          Put yourself in their shoes. You might be providing an accommodation, but are you doing it appropriately, in a way that provides an equitable experience? Here are some examples of what NOT to do:
          • DO NOT use YouTube's automated captioning services.
            DO provide your own specific transcript.

            You have provided the accommodation of closed captions for the deaf, however, most of the time YouTube's automated captions are nowhere near accurate for what the people in the videos are saying, especially if the people talking have strong dialects.
          • DO NOT declare an image as decorative when it actually provides important information.
            DO provide alternative text for your images.

            It's very easy to become overwhelmed by the idea that we need to describe an image when we can see it ourselves, but close your eyes and think about the information you want everyone to get out of your webpage. If it is an event, do the blind users know when the event starts if the only time information available is located directly on the image? Go step by step through your information that is provided for visual users, and determine what, if anything, is missing for your blind users.
          • DO NOT provide alternative text above or below an image.
            DO embed alternative text directly on an image.

            "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect," said Tim Berners-Lee, W3C Director and inventor of the World Wide Web.
            When Tim Berners-Lee (not Al Gore) designed the World Wide Web, he created semantic code that was meant to provide all users with equitable access to content. One of the most abused pieces of code is the alt attribute on an image tag which is where you describe the alternative text of an image. Whether you are composing an email or posting a blog, there is always an option to view an image's properties, and find a menu item somewhere that allows you to describe the alternative text for that image.

            What does putting the text above or below the image do? It calls out, or segregates, the blind users. It is annoying for visual users because it is redundant information. It also continues to make the image inaccessible. After all, what is the point of the image now that the text is available outside of it? Was the image important for the tone of the message? If the tone was important for the message, the visual user has an unfair advantage over the blind user in receiving this message. The blind user cannot enjoy an equitable experience from the image because no information was made available to them that described it.
          As always, I hope to share more of my experiences from these conferences as we continue to learn about new technologies and new techniques for working with them. Very soon, we will be providing some Lessons @ Lunch in the Library to provide techniques for making emails and social media more accessible. I learned a lot from the disabled users of these products, so I hope to see you soon and share the info!