Dynamic Duo drives accessibility at WKU

Laura DeLancey
Laura DeLancey, Electronic Resources Librarian
Shaden Melky, Accessibility Specialist

Laura DeLancey, Electronic Resources Librarian at Western Kentucky University (WKU) and Shaden Melky, Library Technology Consultant (Accessibility Specialist) work well together.

Their teamwork, along with a University-wide accessibility initiative, produces better and richer inclusion for students with disabilities on campus and in their distance learning programs.

Laura, who received her library degree from Indiana University, and then moved to WKU several years ago,  says that what draws librarians into the field is that “people are passionate about providing quality information resources to everyone, from whatever economic background. Public libraries are free. This (working on accessibility) is a logical extension of that.”

“There is a whole population born with disabilities and then there are the many who are aging and their eyes aren’t working as well. I had to redo my own glasses prescription recently at the ripe old age of 32!”

Shaden was practically raised into her current position. She was born in Bowling Green, Kentucky to a family who had immigrated from Syria. Her mother, Huda Melky (now retired) was the long term ADA Compliance Director, Equal Opportunity Director & Title 9 Coordinator at WKU. Huda developed the policies and procedures for ADA compliance that are now the backbone of a university wide initiative for accessibility. Shaden says “my mother started ADA here with Section 504 in the early 90’s, then we updated to Section 508. It’s taken us 20 years to get here.”

Laura chimes in, “It’s almost like ‘why shouldn’t we work on this?’ We work tirelessly to provide access to every other patron group!”

Shaden has merged two life long interests, health care, which consumed her earlier career, and technology.  “One of my biggest things is I like to help people. That’s why I went into health care. Technology is my strength.  By incorporating the two I found my niche.  It’s wonderful for me! I’ve been doing this for 3 ½ years. It’s always a challenge, but then we work it through and meet the challenge.”

An early experience with her gymnastics coach still resonates with her. “I was a gymnast when I was a kid. The coach had gymnasts with Down’s Syndrome or something like that. I still remember watching the smiles on their faces, showing how much they could accomplish. It sticks with me until today.”

University Wide accessibility Initiative

The university wide initiative for accessibility has objectives that cover three main areas:

Librarians and others

  1. OU Campus™, a WYSIWYG CMS (Content Management System) purchased through OmniUpdate. Like over 700 other colleges and universities, WKU uses OU Campus™ to communicate with students and potential students
  2. Library Databases. Like most universities WKU purchases and leases many databases from multiple vendors to allow students and faculty a rich and searchable fountain of knowledge
  3. Distance Learning. WKU has online degrees and individual classes that serve past the borders of the physical campus

The accessibility team which includes the university attorney,  a website ADA consultant, someone who works on the WKU version of the OU Campus™ (@ 700 higher education organizations use this CMS) and a WKU Distance Learning representative, as well as Shaden.

Part of her contribution is to share accessibility reports she has generated using HiSoftware. This is also a time for her to advocate for adding resources like the graduate student they hired through Student Accessibility Resource Center (SARC) who was blind and helped enormously with testing using JAWS screen reader.

“If Distance Learning didn’t have Sam to help with that they wouldn’t have discovered several issues. We’ve incorporated everything he discovered into distance learning and into the library.”

Why use HiSoftware?

Adverse legal actions at another universities prods similar organizations to take concrete action. When Penn State reached a settlement against a lawsuit which claimed lack of access for blind students in multiple software areas, WKU took notice. This led to the decision to include a university wide scanning tool. There are a number of tools on the market which can be used to automatically scan many webpages at a time and provide accessibility audit reports.

“We looked at Deque, which we thought was the best option, but that was out of our price range (at $150K annually). HiSoftware owned by Cryptzone won out. At $20K to purchase plus $1500 annually to update we decided we could work through some of the kinks.”

“In all honesty,” says Shaden, “HiSoftware has been good to us. We run scans on the library databases. We do a mock queries, taking each database, search for the term and locate the resources with the most varied content, like PDFs, video files, etc. If anyone asked I would say that doing a local scan is easiest for databases. We did go through a lot of trial and error with both Firefox and Internet Explorer (IE) scanning systems. There were a lot of glitches and we even got viruses. HiSoftware had advocated for using Selenium, but their own scanning system used through IE proved to be the best. We then went with local scanning as IE is being deprecated.”

Even good software has glitches

HiSoftware generates detailed summary reports which Shaden shares with both the WKU accessibility committee and with vendors to explain the issues with existing software. When she first sent the PDF reports to the vendors they sent back notes. “We can’t open the file!”

After opening a ticket with HiSoftware, both Shaden and the company spent 6 long months testing and trying repeatedly to understand why the reports she could see on her computer were not translating properly to the vendor.

“It turned out that the reports were browser based and needed a special API in the HiSoftware package so we could share the PDFs!”

With that API in place all is well, except… that, because the reports are so technical and detailed Shaden has to produce another “light weight” version for some of the vendors who do not have technical staff on hand to fix the problems.

Laura adds, ” Some vendors would be thrilled if you tell them the line of HTML code they need to fix. Others will have no way of using that information.”

The good news — over time the reports have shown a lot of improvement in the software WKU uses. So, the HiSoftware investment, with Shaden’s inputs and modifications, has really paid off.

VPATs – something to chuckle over

VPATs (Voluntary Product Accessibility Templates) are documents tied to Section 508 compliance. In short, a vendor may be asked by a procurement officer, or within an RFP, to add a VPAT for their software products when bidding on a contract. This VPAT should have resulted from the vendor testing their software against the 508 standards and reporting whether or not the product successfully meets them.

Sounds easy, right?

“Some of the VPATs are very entertaining,” says Shaden with a grin. “When I’m having a bad day I just pull them out and have a look at one of them.”

Laura adds, “It’s really obvious that some of the vendors have a team that works on these, like EBSCO and Elsevier. They are actually familiar with the concepts. Others don’t have a clue as to what we are asking for. I really do think their sales reps fill them out!”

A couple of years ago Laura and Shaden collaborated to check the library database software products against the VPATs provided by vendors. In an extensive and well researched article she shared the results with the library community. Shaden used HiSoftware to check databases against 17 separate VPATs.

Analysis was done (16 out of 17 VPATs proved to be at least partially inaccurate in their self-assessment of their products.) Laura published an article in Library Hi Tech in 2015 with all the details.

“I’ve also compiled some VPATs I have gotten permission to post publicly on a website for Library Accessibility. We are looking for a more permanent home and soliciting up-to-date VPATs to add so that the whole library community can see how the vendors are faring in this area.”


Laura’s responsibilities have changed over the past three years she has been with WKU. While she still participates in accessibility issues, this primarily means that she is involved in procurement, budgeting, consulting with Shaden and presenting at a couple of conferences every year.

“Every year I train librarians on the subject at one or two conferences. We talk about what we are doing here at WKU; what they need to be doing. There is a LOT more interest than there was even a couple of years ago. More people sign up for my workshops. More people stop by after the presentations. And I am not the only one presenting on the subject. There might be 4 or 5 different people involved,” says Laura.

“A great example is the Kentucky Convergence Conference. A couple of years ago we sent in a proposal, which was not accepted. This year the whole conference theme is: ‘Making Higher Education Accessible.”

Another conference Laura presented at this past April was the Electronic Librarian Resources (ER&L) Conference in Austin, TX.  “We did a 4 hour hands-on workshop on how to make resources accessible in the library. I was so happy that there were 3 other programs on accessibility at the conference. It was great that they were librarians that I’d never even met! People are working on this!”

Librarians who have Electronic Resources or Distance Learning responsibilities and titles are the center of the action right now. Very rapidly this is becoming a sought after skill set throughout the library eco-system.


The long term WKU accessibility efforts show how complex the effort is to ensure inclusion for all students at university level with regard to software accessibility. It’s pricy, it’s an ever fluid target and it takes a dedicated team to do it right.

Fortunately WKU has two excellent advocates in Laura DeLancey and Shaden Melky! They are leading the way, building on 20 years of ADA compliance and efforts at the school. And there is no end in sight.

Human face of accessibility

Joseph in wheelchair

joseph in wheelchairThe key reason to plan website and other software accessibility is to enable all people to have equal access to tech. This slide show walks various personas through a popular HR recruiting site. It concentrates on the Assistive Technology devices they use.

A simple thing like using only a keyboard and not a mouse can make it difficult to navigate through a webpage.

If you are using a screen reader because you can’t see the screen and hit an error message which is silent, how do you know what just happened?

If page design is not logical is it more difficult to find what you want on a page when it is blown up to 800% of the designer’s expected size?

To recruiters: 5 myths about QA accessibility testing

woman recruiter reviewing work order

woman recruiter reviewing work orderA new flavor of QA job order is rolling into recruiters nationwide. This is a request for an immediate, experienced QA professional who does accessibility testing. Here are timely suggestions for what the recruiter needs to ask of:

  1. The employer at time of receiving the job order
  2. The candidate at time of initial screening/ interview


First: a short background and list of some terms the recruiter needs to get up to speed on the topic. What, homework!? Yes, homework, so you’ll do your job right.

Even though the ADA (Americans with Disabilities Act) is 25 years old its application to software is still being defined. In short, this means that you are not going to find an exact definition anywhere of what the exact expectation of success is in this area.

With that said, gain some passing understanding of what these two terms mean: “Section 508” and “WCAG 2.0”.

Section 508 is a set of standards the US Federal Government has established to measure the Electronic and IT hardware and software it uses against. Please note that these standards were last updated in 2000 (which is a lifetime ago in internet terms.) A “refresh” of the standards is due soon.

This is where WCAG comes in. While the Section 508 has worked its way through the government process at a snail’s pace there are others in the world working on similar guidelines. Not a law, nevertheless most software companies look to align with these guidelines because they are more comprehensive and up to date. NOTE: Do not try to read most of WCAG. There are thousands of pages and as many ways to implement the guidelines as there are developers and planners.

5 myths:

Myth #1

Screen Reader (JAWS, NVDA) equals a “test tool”.

Reality Check:

Many employers will ask that the QA skill set includes “testing” with JAWS or NVDA.  Do not fall into the trap of thinking that these are test tools.

These software programs are Assistive Technology. They help people who have trouble accessing the internet or such programs as Microsoft Word convert the information encoded on the screen into audio or refreshable Braille outputs.

When testing for accessibility, qualified and aware QA professionals typically use screen readers to validate the end user experience of websites or software programs. This is hugely helpful, but is not the main method of testing.

Recruiter Question to Employer: Are there specific screen readers your users use? In the case of employee used software they probably have a preference. In cases where the software to be tested is for customers you will have to use best practices, which general means JAWS for US based companies. NVDA is also widely used.

Recruiter Question to prospective QA Employee:

What test tools do you use to validate the code against accessibility standards?

[Give points for answers such as WAT (IE toolbar from The Paciello Group http://www.paciellogroup.com or WAVE toolbar (Firefox and Chrome plugins from Webaim http://webaim.org).

Give points for answers which discuss evaluating the code for items like form labels, WAI-ARIA roles and properties]

If the QA person says they use JAWS, for instance, to test with, ask them how they do that.

Myth #2

User Experience is the same for all users.

Reality Check:

Even if a site is usable for the general public there is a need to do additional usability tests for people with disabilities (PWD)

Real example:  the code was properly designed to be read by a screen reader, but because the fields in the design of the screen were set up in a certain order the screen failed the usability test.

A resume upload page on a very common HR recruitment site had an input box below the Submit button. The sighted user could easily see the Comments box and choose to type something like “Portfolio” or “Cover letter”. The blind, screen reader user would not encounter that box until AFTER they had submitted their resume. At this point there was no chance to add the comment or go back.

The page passed the Section 508 and WCAG criteria but failed the simple usability test.

Recruiter Question to Employer: Will there be an opportunity in this role for the QA person to discuss the site with designers and/ or product managers?

[Give points whenever an employer understands that this discipline is a cross-functional, cross-team effort.]

Recruiter Question to prospective QA Employee: What experience do you have with creating/ testing against User personas? How much experience do you have working with people who need assistive technology (AT)?

[Give points for any recognition of what UX is, what personas are and, most of all, if the QA resource has worked with PWD.

Give points if the QA resource has had any experience explaining that websites/ other software may present challenges to those who are using AT. If they have done so, ask them to describe the outcomes. ]

Myth #3

You have to test all pages on a site to do an accurate accessibility test.

Reality Check:

Given that so many sites have hundreds, or even thousands of pages, it is impractical to comprehensively test them.

The usual method is to concentrate on the primary pages which handle the most user traffic. (Home, Search results, Contact us, main shopping and check out pages, etc.) If those pages reveal serious problems they must be fixed first. Only later should the testing go deeper. Additionally, newly coded and added pages should include accessibility testing as they are prepared for production.

Recruiter Question to Employer: Will the QA resource be presented with the core workflows so they can include them in the testing? Who has developed the initial test plans?

[Give points if Product Management is involved]

Recruiter Question to prospective QA Employee: How many scenarios do you usually test? What are the main paths? Do you find that pages deeper in a site present different challenges than the Home page?

[Give points for any answers that indicate that the QA resource is familiar with accessibility being disproportionately built into the Home page and ignored further into the site. Give points to a QA resource who mentions that some features, while not on every page would warrant special testing – forms, videos (for captioning and general keyboard accessibility of video player controls)

Myth #4

Anyone who has a degree in Computer Science would know how to test for Accessibility.

Reality Check:

Fact is that most of the computer science programs, boot camps, and assorted free and for-pay courses do not even touch on accessibility related coding. Most of the programmers who know how to prepare their code for consumption by assistive technology and people who use alternative methods of understanding the UI have learned it “on the job” or by doing research on their own.

Recruiter Question to Employer: What specific skills are you looking for in a QA resource to test your site/ software for accessibility?

[Give points for any answer that acknowledges that most resources will not have gained this knowledge in a common computer science program. Give points if the company already has some knowledgeable people on the ground who can help the new QA resource.]

Recruiter Question to prospective QA Employee: Where did you learn about accessibility and accessibility testing?

[Be prepared to hear a long and drawn out version of their discovery process. Be patient and take notes. Do not believe them if they say that they easily discovered it in a class or another job.]

Myth #5

There is no need to do manual testing, because all the tests can be automated

Reality Check:

While there is much merit to automating as many checks against clean and correct code bases, even the most progressive automated testing tools can only check code violations (HTML mis-matches, for instance).

None of them can accurately replicate either the user experience for a person using keyboard only approach or various assistive technologies: See Myths #1 and 2.

Recruiter Question to Employer: Are you expecting to have the QA resource convert some of their tests to an automated system? If so, which one are you using and are you aware of any necessary accessibility plug-ins that will be required?

(Give points if they already understand that there is a limit to the usefulness of applying automated testing across the board to this effort. Part of your role here is to help set expectations of what is possible in reality.)

Recruiter Question to prospective QA Employee: Have you ever committed your accessibility tests to an automated process? If so, which one? How effective has this been? What do you know about accessibility plug-ins for the major automated test systems?

(Give points for honesty when the tester has not been able to do much useful with automated tools. Give big points if they mention anything covered in this article by CogApp or this one where researchers in Norway examined the results of 12 automated accessibility checkers. Yes, done in Norway, but the checkers are global.)

Wrapping it all up:

QA can and should do testing re accessibility diligently, deliberately and determinately whenever a software project is undertaken in 2016. However, that QA is by default dramatically different from other areas of QA.

Get familiar with the ins and outs and prepare to make significant money for your recruiting firm and your QA resources. This is a niche that is not going away.  Think about placing QA security testers and prepare to reap the benefits in the same kinds of ways.






Accessibility jobs

subway to work

Who is working in Accessibility now?

subway to workIt was intriguing to read Webaim’s July,  2014 survey results of accessility practioners. Vast oversimplification: 900 respondents, 90% of respondents work in US or Europe, 1/2 of them work in accessibility as a “primary” part of their jobs, however @ 60% of them work on accessibility less than 20 hours a week. Only 22% said they were developers and only ~4% said they were QA professionals. These numbers will get interesting later in this article. Median salaries were between $60k and $80k but fluctated widely depending on amount of time spent in accessibility, education levels, and industry (government/ corporation/ consultancy).

Reading (and participating) in the survey started me wondering if the field is getting more exposure. Are there really more jobs? What industries are looking to pay salaries to people with accessibility related skills?

So I set out to answer some basic questions. How many jobs are there in Accessibility? What kinds of skills are employers looking for? What is the growth potential in the market?

Gathering stats on accessibility jobs

Query on www.indeed.com on October 25, 2015 using “%Accessibility%” in the title. No limits on location other than the United States. There were 107 results, some of which were redundant. Multiple recruiters were hawking the same position. Culling for duplicates I found 80 jobs. They are heavily weighted to IT (half were for developers or QA professionals), almost ¼ were management or administrative positions and the final ¼ were a mix of electronics, UI/UX, technical workers.

When I searched more broadly within indeed.com using just the term ‘accessibility’ to pick up any jobs using the word in their descriptions I found 11,442 jobs. Unfortunately, many of these job descriptions include a phrase like “if you need accessibility accommodations to apply for this job, please contact <email and or phone number>” In other words, the jobs are NOT about accessibility.  Other off track uses of “accessibility” or words that stem from it are: “Access” databases, job includes enticing ”access” to areas of beaches, skiing or other amenities or job duties include “providing access to systems for onboarding new employees”.

The jobs that truly include some skills or expectations of understanding about This confirms our finding of the 80 jobs on indeed.com which used the word in the title. More and more development opportunities include a mention of accessibility, especially for front end and full stack developers. Even though it is still rare to see the proper skills taught in computer science classes, the subject might be mentioned in boot camps. Anecdotally, developers just run across a request to “make the site accessible”, leading to them doing whatever research they are capable of and/ or have time for.

Query on www.linkedin.com on October 25, 2015. Same criteria as above. Job title contains “%Accessibility%”= 58 results. Keyword contains “accessibility” = 5,303 results. Again, roughly half were development or QA jobs, about a quarter could be cast as management/ administrative and the last quarter didn’t fit neatly into any category, thus we’ll call them “other” for the moment. Again, most of the jobs in the larger data set either reference the employers willingness to provide specialized accessibility support for their candidates or include some other use of “access” which is not relevant to our search.

Skills requested

What are employers looking for? From job descriptions:


“If HTML, JavaScript and CSS make you want to get out of the bed in the morning, this is probably  a good job for you.” – SSB BART Group, San Francisco

“Experience preferred in WAI-ARIA, HTML, CSS, JavaScript, AngularJS (optional)” contract in Richmond, VA

QA testers:

“Screen readers, voice recognition, html/ CSS. Knowledge of industry standards and regulations (WCAG 2.0). Use of automated testing tools.” contract in Richmond, VA

“Be able to educate and guide engineers in best practices. Use and help improve existing processes.” Redmond, WA

Accessibility Lead:

“BA in HCI, Engineering or equivalent professional experience. Thorough knowledge of Accessibility guidelines. 5 years experience creating accessible products and using assistive technology. Three years native mobile experience with iOS/Android/ Win8/ web mobile expe