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 dialogue, 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.