Monday, July 28, 2014

#MondayFunday: Cappuccino Lays

In order to make our Monday morning a little more bearable, I brought in the new Cappuccino Lays chips to do an office taste-test.


The only person who really liked the chips was the same person that does not like potato chips OR coffee. Go figure!

-Daphne

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!

-Daphne

    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.

    Content

    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.

    Headings

    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.

    Links


    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.

    Images

    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.

    Paragraphs


    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.

    Tables


    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

    -Karole

    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

          Language

          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.
          -Karole

          Monday, June 23, 2014

          Searching for a search

          Inception

          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.

          Creation

          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).

          Feedback

          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.

          -Ernie

          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!

          -Daphne

          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!

          -Morgan