Monday, February 16, 2015

The Difference Between Hearing and Listening

Two interesting articles came out last week about accessibility issues in higher education, one nationally and one locally. In national news, the National Association of the Deaf is attempting a class-action lawsuit, filing two first against Harvard and MIT on lack of appropriate closed captioning of online videos or educational materials. In local news, the JTAC Sports News Editor Lura Rylant willingly gave up her ability to walk across campus for a one-day experience as a student who would have to use a wheelchair.

"If a tree falls in a forest and no one is around to hear it, does it make a sound?"

It's a philosophical question that came to mind as I started to compare these two articles. It's often thought that if a person does not make a complaint about being discriminated against, then no discrimination is taking place. Everything is good, right? But there is a difference between hearing (acknowledging the need for compliance) and listening (understanding and taking action towards creating a non-discriminatory environment).

The Sound of Change... and Challenges

The statement in the NY Times article that “much of Harvard’s online content is either not captioned or is inaccurately or unintelligibly captioned, making it inaccessible for individuals who are deaf or hard of hearing” makes me suspect that the inaccurate or unintelligible captioning was done by automated captioning programs under the assumption that since YouTube and other services provide it, no inspection of the final resulting captions are needed. Comedians Rhett & Link bring this misconception into light in a series of videos:

The closed captioning article blew up my accessibility mailing lists through the weekend. Since the automated services are not accurate, manual transcribing and caption synchronizing is required, but many on the lists are concerned that closed captioning is time consuming. Here at Tarleton, Web Services timed the transcribing and captioning process. It took about 20 hours, with no other tasks assigned, to caption an hour's worth of sound effects and dialog, but we still attempted to do it this way for a number of months. Meanwhile, we received numerous videos to post, and the task queue got severely backlogged. Some videos needed to be posted sooner than the time it took to caption them by our own staff and interns.

That's when we looked into outsourcing, as have other institutions, but that is still an expensive option. We are currently trialing different services just for videos that go through the official YouTube account managed by Marketing and Communications, but imagine expanding that price tag to all videos from all departments, including all current and archived videos? No one department, and likely entire university, would have the budget to handle that process, so accessibility coordinators are trying to find other options, including crowd sourcing, to speed up the captioning process.

The intention of these lawsuits is obviously to draw attention to the need for deaf and hard of hearing students to have the ability in the here and now to participate in their classes like their fellow classmates as well as ask a broader audience what we can do to improve this process. Everyone is hoping the federal government will provide some type(s) of guidance:
  • An education discount on transcribing services?
  • A reasonable time between posting and closed captioning in proportion to video length?
  • An increase in jobs for audio/video transcribers through government assistance?
We will keep an eye on the results of these lawsuits. In the meantime, we still need to do our best to get new videos closed captioned and audio files transcribed.

Putting Yourself in Another Person's Shoes

I have to extend a major kudos to Lura Rylant for attempting this major lifestyle change for even one day in order to observe, from her own perspective, the life and daily routine of a person with motor function disabilities. It requires a lot of courage to face this kind of challenge when you can easily get up out of the chair at any second and call it quits. Imagine how many people who cannot make that decision: any one of us could come out of an accident or a health issue with some kind of disability, and many veterans risk their lives and pay the price with a part, or parts, of their body. Disability holds no prejudice.

All universities strive to make their campuses accessible to all their students, faculty, staff, and visitors. As I mentioned in a past article on 50 Shades of Universal Design, not all accommodations, though well-intentioned, are designed universally accessible. In her opinion, some of the issues Rylant experienced with our accommodations may not have had her safety properly evaluated and planned. She also had some interesting concerns that Web Services would like to assist on such as adding accommodations to our maps, so people know where things like ramps and elevators are located. Adding accessible accommodations to our new interactive map was placed in Phase II of our campus map conversion, since Web Services doesn't have a list of these resources and would need help rounding them up across campus to add onto the online map.

One thing to note about these incidents and observations is that no one is trying to punish anyone for not being fully in compliance with accessibility standards and anti-discrimination laws. Many of the lawsuits involving ADA actually end in mitigation where all sides work together to resolve observable problems and initiate constructive guidelines for accessibility. These are problems and challenges that face a global community, and we don't all readily have the answers to each one.

While Lura Rylant has knowledge that will make her more sensitive and sympathetic to the issues affecting other people's lifestyles, we cannot educate everyone by placing them in wheelchairs, blindfolding them, or plugging their ears, so they understand the level of accessibility of the accommodations around them, physical or virtual. That is why we have federal standards (such as the past mentioned example 405 Ramps in Chapter 4: Accessible Routes of the ADA standards website) for architects and engineers to abide by when building physical accommodations. That is also why states like Texas require all state-funded universities and agencies to have accessibility coordinators. We act as liaisons and educators as we take notes on the issues concerning people with disabilities interacting with technology.

If you are an individual with a disability, Tarleton has avenues you can take through our disability services. Everyone has the right not only to be heard but to be listened to.


Thursday, February 5, 2015

A Picture is Worth a Thousand Words... Literally

Writing alternative text (or an image description) for graphics, charts, diagrams, and other media that may be important to convey a message or inform users has now gotten a littler easier. The National Center for Accessible Media has added a new resource that will specifically help faculty with examples they typically post on lecture and test materials: Item Writer Guidelines for Greater Accessibility.

Oftentimes, accessibility and usability come hand in hand. While these guidelines are intended to assist users with visual disabilities, they can also assist faculty on designing test items or materials that are easier for users with other disabilities (or none at all) to understand and interactive with.

And, in general, they are a good resource for graphics usage on all websites and electronic materials.

I've included it and some of their other resources on the Web Accessibility website, under Agencies/Organizations, for your use. Please check this website periodically for new resources.

As a reminder for all Cascade Server users, we still have useful information on graphics in our CMS Tutorial: Tips and Tricks site that we have not moved over to our blog:

Wednesday, February 4, 2015

Catching Up: Web Services in January 2015

Despite the break in December, we've never slowed down in Web Services since we came back. Some of the highlights include working on improving publishing services through Cascade Server, improving project management processes for web updating/programming, and preparing for the 2015 Texas A&M System Technology Summit next week in Galveston where we will be presenting at not one but two sessions!

Cascade Server Publishing Queue

Despite positive results from stress testing the publishing queue when using the hosted solution through Hannon Hill, we were hit by numerous problems when we moved the service off Tarleton's physical site. Hannon Hill has been very helpful assisting us and our server team in troubleshooting the issues. While there are a few bugs that still need to be fixed on Cascade, we also found that many of the problems were user error. Moving forward, these are the things all web maintainers need to keep in mind:
  • Unless you have made changes to the left navigation, footer information, or multiple changes across the website, you should avoid publishing entire folders. If you are publishing entire folders, please select only one destination: WWW/Full Site/WWW - main
  • Make sure all files are named appropriately (i.e., no spaces, dates) and with common file extensions (i.e., filename.jpg, file-name.docx, name-of-file.xls, the-filename.pdf). Please use ZIP files for content that does not use common file extensions.
  • Please remove all unnecessary files from Cascade, or we will remove them when they block the publishing processes from completing successfully. Cascade is not storage, and the web server cannot handle non-Windows based file extensions (i.e., files only used on Macs).
Presenting Our Experiences at the Technology Summit

Many members of The Texas A&M University System have not made the inevitable leap to responsive design, so the System invited us to present our experiences of going responsive, completely in-house with a full-time staff of only four people. Our entire full-time Web Services team will be there to present on the topic. The below mentioned Project Management process change will be a part of our Lessons Learned as we present to our fellow System members our timeline for converting to responsive.

No conversion should be done without serious thought and understanding of this complex technical process. As we compiled our timeline, we also looked at how many training sessions, webinars and conferences we've attended to get to this point. During the last several years, we've participated in at least 57 total training sessions: 19 with topics more focused on accessibility, 26 on content strategy, 27 on web development, 18 on marketing, 32 on strategic planning, and 12 on responsive web design. We feel like we never left college... literally and figuratively.

Daphne Hunt will speak with TAMU colleagues at an additional session on our experiences working with Hannon Hill's Cascade Server. Tarleton is one of the oldest members in the System to be using Cascade having started in the spring of 2009. That's right, we are in year six!

Project Management

We receive numerous tasks via emails, walk-ins, phone calls, and committee requests every day, and with our growing staff, it was becoming more challenging to track all these processes as well as keep everyone informed of what project was being done by whom. We are working on multiple solutions to improve this process. 

New Request Web Updates Form

Located on the Web Services website, the new Request Web Updates page explains what updates and web development can be requested or needs to go through a different process. Once you've read through and become familiarized with the process, you can directly request web updates or development. Web Services may contact you for further clarification or instructions on how you can make certain updates.

These requests are automatically placed in our project queue maintained by Morgan Hammond who delegates these tasks to our student interns or office staff where needed based on the priority and due date provided in the request.

For the month of January, Web Services has completed at least 85 requests, including the design of numerous digital ads.  We also started training two new student interns, Colton Sheffield and Yaritza Corrales, and we provided 4 Cascade Server training sessions in the Library Training Center. 

Getting Sass-y Behind the Scenes With Process Changes to Web Development

While we make updates to the old website, we are still in the arduous process of building the new responsive web pages for departments to use. This is a very technical task and requires more than one set of hands (or creative minds) to accomplish, however, the way we've been approaching development has been quite old school and needs a millennial facelift.

For example, the web developer and web programmer in our office receive numerous requests all the time to make adjustments to our single CSS file which controls the look, feel, and behavior of our website. Let's say theoretically (though events like this really do occur) the University Digital Advisory Committee wanted to do AB testing of a module while we are fixing a problem with the latest operating system for iPhones while we are working on new responsive modules for departmental webpages while we are fixing the search engine results look due to a different bug. *deep breath* This is a time consuming process to compare all copies of our CSS for all the above solutions and implement a single CSS file with all the proper corrections. Without making any mistakes. *exhale*

Most web developers nowadays approach the CSS through a "preprocesser" (before compiling into a single file) script. CSS is a programming script for all the aesthetics and interactions you see on the browser, however, using an extension like Sass (Syntactically Awesome Style Sheets) or Less (commonly known as LESS) allows multiple developers to work on different aspects of the style without stepping on each other's toes and do so with programmers' favorite tools, like variables and functions, to repeat common processes without as much work.

This allows us to do proper AB testing where we can adjust a single aspect of the CSS file by compiling only certain Sass files and inserting them on test pages without breaking other parts of our CSS that we may be fixing on another set of Sass files. We control which pieces are available where we need them, moving large blocks of code instead of very small, delicate lines of code.

We go back and forth on when we should have started using Sass. Our plan in Project Squishy was to roll out the new responsive design during a time when the students could get used to it before classes started up again. We were more comfortable working directly with CSS, knowing that converting to Sass would be a huge learning curve and slow down that process. That being said, there are numerous instances, like the theoretical set above, that could have been resolved faster had we moved slower with the roll out of Homepage 1.0. Having many of the new modules in place behind the scenes for the departmental pages even before Homepage 2.0 was implemented, we are having to go back and convert everything to Sass to make the process faster in general. To be honest, it was going to slow development down at the front end or back end of the development process no matter what. Good? Bad? You can't learn without making a few mistakes. We think these will be good for everyone in the end.

Wednesday, December 10, 2014

New Department of Justice Settlement Increases Scope of Web Accessibility Compliance

A recent United States Department of Justice (DOJ) settlement with Ahold USA., Inc. and Peapod, LLC (Peapod) expands the scope of compliance with Title III of the Americans with Disabilities Act (ADA), which includes providing standards for accessible public accommodations.

Originally, public accommodations were defined as those the public could physically access, however, the DOJ has expanded the definition since 1990. Increasingly, the DOJ has concluded that this includes commercial facilities and websites.

However, this most recent settlement agreement with Peapod is opening the doors of accessibility compliance to include websites that don't have a physical, or "brick and mortar," location for the customer to visit as well as mobile applications that customers can download and/or purchase.

This means that if you build a cool game for a mobile device or even a better functioning email app than the one installed by the device's manufacturer, despite not having a physical location to serve the customers downloading/purchasing your app, you may be sued for discrimination against individuals with disabilities.

This comes on the heels of a Section 508 Refresh for the US which is expected to occur in 2015. Section 508, an amendment of the Rehabilitation Act of 1973, had its last standards written in 2000. These standards are based on a larger encompassing Web Content Accessibility Guidelines 1.0, or WCAG 1.0, authored by the World Wide Web Consortium (W3C).

It was a bold move to attempt to define standards that would give all individuals with disabilities access to electronic and information resources given the technology of that time. It has, in fact, been determined to include many holes to access, barely serving individuals with disabilities beyond visual and hearing impairments and missing other ability issues, including cognitive and motor function impairments.

As the standards were implemented, the W3C reconvened to resolve these disparities as they were discovered and technology improved. WCAG 2.0 was recommended in 2008, and numerous countries jumped on board to accept WCAG 2.0 as their standards for accessibility compliance. While the US books still claim we follow the WCAG 1.0, the DOJ has made many rulings in favor of WCAG 2.0 in order to provide access to the entire disabled community, including this most recent settlement agreement with Peapod.

As an institution of higher education that receives both federal and state funding for the programs we provide our community, we must acknowledge these changes to the standards and be ready to comply to the upcoming standards in a reasonable amount of time. That time is growing shorter as these legal proceedings show we've been receiving a fair warning of the future of accessibility compliance. I have and always will provide any accessibility solutions based on WCAG 2.0 recommendations in order for us to move forward as quickly as possible with the conversion of our electronic and information resources and ensure we are providing access to all individuals no matter their abilities.


Tuesday, December 9, 2014

Happy Holidays from Web Services!

We hope everyone has a joyful month, and let's hope for a little snow while we are on holiday break!

Happy Holidays from Web Services!

"Meet the Staff" Series - Morgan Hammond, Content Specialist

Name: Morgan Hammond
Morgan Hammond
Titles: Content Specialist
Length of time in Web Services at Tarleton: 3.5 years
Length of time in web occupations: 7 years
Top three areas of expertise: Content Strategy, User Engagement, and Copyright (particularly the TEACH Act)
Topic interests: Same as above with added interest in web usability, cultural diversity, photography, and animal production
Favorite thing about my job: Learning and the practical application of things you never thought you would use.  This field requires you to think on your toes. Just because something has worked in the past does not mean it still applies.  New and emerging technologies pose challenges to the way our students learn, engage, and transition into the real world and I am always intrigued by the way students relate to and use new technology.  My job never gets old!
Hobbies: Decorating! I love to redesign, reimagine, and repurpose everything from farm implements to things in our "junk drawer".  The launch and success of Pinterest only fuels this obsession with redoing!

A "Day in the Life":

  1. Email.  I wish I didn't feel the need to check it first thing because it sucks you in.  You know what I’m talking about.  If I'm not careful, I will "waste" away precious time analyzing new solutions to the world’s problems that arrive at my doorstep via email, even if the initial question is simple.  I strive to provide useful feedback concerning web content that may or may not have been the focus of the initial email.
  2. Check in with the web interns to see if there have been any new developments in project status, development requests, training needs and conversations within their colleges.  Sometimes I am able to help fill in a few details from ongoing projects or past work done with individuals to help in the completion of a project.
  3. Answer a few calls about Cascade questions or training.
  4. Lead an "official" Cascade training.  We typically provide a group training session once a week in which new maintainers learn the basics of Cascade.
  5. Review and/or comment on some of the interns’ work.  We can all use an extra set of eyes when publishing content to the web.  This way our interns learn as they go, can ask questions if they need to, and I learn more about their strengths and weaknesses.
  6. Make updates to a site upon request, while also looking for things like overall usability, accessibility and copyright compliance.
  7. Generate analytic reports upon request.
  8. Consult with a client or a teammate about my findings working on a new or existing site as it relates to a client’s expectations and audience or how it will affect my team from a programming or design standpoint. 

Wednesday, December 3, 2014

Homepage 2.0 Goes Live Today

Web Services has been working on solving a number of bugs found on the homepage and making some improvements to the page interface for better functionality on all devices. After all the device testing, we are rolling out Homepage 2.0 today.

Homepage 2.0 Bug and Change List

  • Bug fixes for iPhones, Androids, and Windows Phones.
  • Fixed hanging on scrolling up and down the page on mobile versions.
  • Fixed expanding/contracting menus on mobile navigation.
  • Improved mobile navigation.
  • Fixed background page appearing underneath mobile menus and search fields.
  • New and smoother header reveal on scroll up and disappear on scroll down to provide more real estate for page content.
  • Mobile navigation appears and disappears smoother.
  • Improved tabbing through items and navigation on the page.
  • Improved form field validation checking.
  • Improved load time.
Should you discover any problems or have compliments on the changes (we love hearing when we've done something right), please Submit Feedback on the Changes for the Homepage.

Technical Bug and Change List

Mobile-Specific Bugs

  • iOS8
    • scroll unresponsive
    • mobile main Menu jitter
    • quick double tap closes menus
  • Windows Phone
    • search clicks register to other elements
    • scrolling in mobile windows phone during search scrolls down to main page

Sticky Header

  • added 3 states to the mobile and desktop header
  • transitions between hide, show, and -200px off-screen
  • major  CSS changes supporting elements to allow position relative as a default position when resting at the top

Lazy Load Bugs

  • $("[data-original]”) looped to itemize each element after the dynamic elements are loaded
  • fixed footer images not loading properly

Form Inputs and Validity in Webkit

  • HTML5 enforced validity for HTML5 compatible browsers
  • JS added code to enforce validation in Webkit.  
  • Webkit requires special CSS in iOS to display properly

Collapsify (for expanding/contracting menus, etc.)

  • modularized plugin for collapsing elements
  • optional and default closed and open elements
  • list item as a link not working

Sliderific (for sliding images, news, etc.)

  • now accepts position and button size

Top Nav Hide/Show Delay

  • same as banner code
  • code is in stacked template

Dynamic Menus

  • basic ul li elements
  • datetimestamp to pull fresh data every time minimize cached elements
  • Collapsify after instance load

Unified Mobile and Desktop Search

  • made search a separate div for flow and accessibility
  • moved search default position farther off-screen in CSS as default position in mobile
  • float width bug
  • float over login hides search
  • search font sizes
    • mobile
    • desktop

All Animations are 3D CSS

  • to top
  • audience and main mobile menus
  • search
  • sticky header


  • strange block appearing after search results elements removed
  • appears modal with a grey background on desktop
  • improved More button and flow functionality


  • only hide tags 
  • indent all code appropriate to width
  • removed deprecated code

Changes in Cascade Server

  • moved around elements in template and created new instances
  • added document.ready to Tarleton F.O.C.U.S. block in all stacked template modules
-Karole and Ernesto