Accessibility goes beyond availability. It’s about being inclusive and it’s about making it so that all users can consume, interact with, and navigate your internet resources. To do this effectively, you have to first understand how folks with disabilities use the web. Then you can evaluate your site using tools and click-throughs to identify any weak areas, and then you can make corrections and updates. We’ll go through these steps, and then I’ll round out the blog post at the end with some tips for different media types. If you follow these steps diligently, you should have a great start at making your content available to everyone. In a future blog post, I’ll talk about how responsive design and making an effort to make your resources cross-platform compatible can further broaden your audience and bring down accessibility barriers.

If you haven’t listened to the last podcast already, go ahead and give it a listen. It’ll give you a great introduction to this topic and explain why accessibility is so important to accommodating your users, staying out of trouble, and broadening your base.

Understanding How People With Disabilities Use the Web
Assistive technologies have thankfully come a long way in recent years. When creating and producing content for the web, it’s important to realize that not everyone will be consuming it or navigating it using a keyboard, a mouse, or even a screen. For instance:

• Blind and vision-impaired users frequently use screen reader software. This software reads out, using a synthesized voice module, words that are displayed on a screen. It’s vitally important to craft your HTML and your navigation with screen reader technology in mind. In addition to screen reader software, there are screen magnification tools that some folks will use to enlarge sections of the computer monitor. Some may also run their screen in a low-resolution, highly-magnified environment. It’s important when designing your websites to make sure that they scale up and down appropriately. When it comes to input, there are braille-compatible keyboards that are available.
• The web is typically a welcoming environment for deaf users or those with auditory impairments, but more and more content is being released on video now. These users need subtitled or even sign-language videos in order to consume this type of content.
• Folks with motor control impairments may use special input devices, many of which don’t resemble a typical mouse or keyboard setup. They may also use speech recognition software as inputs.

This isn’t an exhaustive list, but it’s enough to get you thinking about some of the design and content considerations you’ll need to work out as you present your content.

Identifying Problems Using Tools
As I mentioned in my podcast, there are basically two major accessibility checklists that we follow. Here are a few tools that you can use to help you evaluate your web resource and help you adhere to these standards:

If you’re just getting started, a quick and dirty tool that I like to use is WAVE. It’ll quickly show you any potential issues, highlight some positives, and let you get started in no time at all.

One that we’ve been quite fond of in the university setting is Powermapper. We used this tool to get Section 508 compliant in short order.

Compliance Sheriff is quite thorough and is definitely an enterprise-level solution to this problem. One of the benefits of this is that you can very easily test web resources before you launch them to ensure that your content will be ready for prime-time starting on day one.

Identifying Problems by Using the Site Yourself
I definitely recommend using one or more of the tools above to show you where some of the weak points are in the accessibility of your resources, but they won’t tell you the entire story. The best possible way to find out what types of problems might exist is to actually use a screen reader, a different type of input device, or a screen magnifier yourself to see how your website holds up. If you don’t have access to such tools, then carefully examining your information architecture, hierarchical layout, and the way you’ve set up your navigation will go a long way toward helping your readers, since most accessibility problems that tools can’t catch stem from these areas.

Specific Actions to Take
By now, I’m sure the tools and your own exploration have identified some areas that need work. Most of it will refer to markup problems in forms, missing alt or title tags in the the HTML, and various problems like that. Those are easy to fix, though it might be fairly time-consuming.

When it comes to other issues, the important thing is to try to apply common sense to your designs and content. Don’t use images in the design if you can help it. Bright colors, strange contrast, and flashing/strobing effects can cause problems for a variety of users.

Some Tips for Different Media Types

• Flash and other plugin-based content typically scores very low on accessibility and should usually be avoided
• Videos must have subtitles and transcripts
• Audio must have transcripts
• Avoiding PDF if you can (there’s a right way and a wrong way to do these)

Final Thoughts
You’re most likely fixing a lot of these things after you’ve launched something, but going forward, try to adopt a workflow and a philosophy that includes these things from the beginning. Designing and creating with accessibility in mind from the ground up is the best way to ensure a smooth, effective, and efficient rollout of 508 and WCAG-compliant content — content that everyone can use.

Next time we talk about accessibility, we’ll discuss how responsive design and making an effort to make your resources cross-platform compatible can further broaden your audience and bring down even more accessibility barriers.

If you have any questions or comments, feel free to leave them below, or email me at keithkomos@gmail.com.

Today we discuss a few basics and guidelines related to accessibility. In the future we’ll be diving deeper into some of these topics.

by Keith Komos

What is Orcid?

Orcid is a service that provides you with a numeric identifier that ties you with your scholarly output. For those of you lucky enough to be named “John Smith” or something else that’s quite common, Orcid will help folks find the real you. If your name changes because of marriage, or if it has any inconsistencies, or if (like in the example I just provided) you have a very common name, Orcid solves a lot of problems for you.

Research institutions have been pushing this technology because of how much easier it makes academic life for faculty and grad students. Your publications and output can, often automatically, be added to your Orcid account and then that can be proliferated across all kinds of different systems.

What are we trying to do?

Since research institutions are the early adopters of this technology and there are various outreach efforts across hundreds of organizations right now, a way to evaluate and track how many folks that have actually signed up for Orcid in your organization would be quite helpful. Orcid doesn’t provide a very robust searching or filtering interface for doing this, but luckily they do provide a public API that allows us to ferret out this information.

What do we need before we start?

• Your organization’s Ringgold number
• A free Orcid account of your own in order to connect to the API
• A bit of programming background
• Access to server software and a database.
• Knowledge of how to connect through OAuth. That’s how the Orcid API let’s you in.
• I’m using an Apache server with PHP installed and a MySQL database.

How do we do it?

Create a database with a few fields like name, orcid_id, education, and employment.

Connect to the Orcid API using the OAUTH protocol to get your unique token. Save this token to a variable because you’ll need it for every API request.

Formulate your initial query. You may need to make several passes to get everything, since Orcid groups returns in batches of 100. My query for the University of Houston looked like this:

"search/orcid-bio/?q=14743+AND+HOUSTON&start=“0”&rows=100";

Replace “14743” with YOUR organization’s Ringgold number. The other part is optional but it helped me reduce false positives. Also, I specified in the HTTP header that I wanted JSON to come back, and used CURL to make the command. Here’s my header:

 $header[] = "Content-Type: application/json" ;
 $header [] = "Authorization: Bearer " . $token;
 $ch = curl_init("http://pub.orcid.org/v1.2/" . $query);
 curl_setopt($ch, CURLOPT_HTTPHEADER, $header);
 curl_exec($ch);
 curl_close($ch);

So with these results, I simply parse the JSON and save the name and Orcid ID to the database. Nothing with Employment or Education yet, since this API call doesn’t return that info anyway.

You could actually stop here. But I want to know if their education was at the University of Houston or if their employment is/was. To do that, I need to traverse this list, using the Orcid ID numbers of everyone I just pulled in, and get that additional information. This query is very simple:

$orcidID . "/orcid-profile";

Again, I specify JSON as my return. This gets me the education and employment information I wanted to add to my stats. But here’s where it gets a little weird. I want to save these arrays as strings, so I need to convert them. I make a special point to capture the beginning and end date, so that I can determine if they are a current student or employee. Here’s my code for that:

foreach ( $data['orcid-profile']['orcid-activities']['affiliations']['affiliation'] as $w):
         if($w['type'] == 'EMPLOYMENT') {
             $employment .= $w['organization']['name'] . '---' . $w['department-name'] . '---' . $w['role-title'] . '---' . $w['start-date']['year']['value'] . '-' . (empty($w['end-date']['year']['value']) ? 'Present' : $w['end-date']['year']['value']) . ';;';
         } 
 endforeach;

We’re done querying the ORCiD API, but even with the cleaning up and reformatting we’ve done as we went along, there’s still a bit more to do. We now write a simple script that goes through and looks for the phrase “University of Houston” and the word “Present” in the date part of the string. If they both occur then we flag it as a present student or employee. We can also reduce false positives at this point by deleting records that don’t contain “University of Houston” anywhere in these fields.

Now what?

Tally it all up and display it in a table if you want to. Now you have a membership baseline for your institution. How many employees? How many students? You can go through the process again on a quarterly basis or so to see how membership changes over time, and use these metrics to measure the effectiveness of an Orcid outreach campaign.

Drop me a line if you have any questions!