The latest revision of the Web Content Accessibility Guidelines (WCAG), version 2.1, was recently published. While it’s a few years old, I still often refer to my series of blog posts that break down WCAG 2.0 because unlike many of my other articles on web accessibility, it refers to the WCAG criteria by number. This extra part to the series is to specifically cover what’s new in WCAG 2.1. Continue reading “Making Your Website Accessible Part 4: WCAG 2.1”
This was originally presented as an online workshop for the Center for Instructional Development & Distance Education, University of Pittsburgh on February 5, 2015. If you’re familiar with my presentations, everything up to and including the introduction to universal design is quite similar to my past presentations (especially the most recent one). However, after that, this presentation focuses solely on creating content, both online (such as using WordPress) and using software (such as Microsoft Word). As you can imagine, this presentation was geared towards non-technical users, going into much more detail on content guidelines than in any of my other presentations, and for UPitt faculty and staff. Continue reading “Presentation: Making Accessible Content Easy and Part of Your Work”
So I promised
@gmcharlt a while ago (think last November) that I would do a blog post on comparing how the US and Canadian legislation regulations align with the Web Content Accessibility Guidelines (WCAG) 2.0. Continue reading “Alignment of WCAG with Section 508 (US) & Canadian Legislation”
We have two existing guides that help coordinators and students decide on their preferred format, but they seem to reflect all the formats we could produce rather than the more practical reality of what we normally produce. Continue reading “Guide Reflow: Deciding on Your Accessible Format”
If you’ve read my previous posts on web accessibility, then most of this will be a rehash. This is the version that I did for the TRY 2013 conference, where I reorganized a few things and put in different examples. Continue reading “TRY 2013: Implementing WCAG by Making Your Website Accessible for Everyone”
This is actually a repost of my guest post on the ACRL TechConnect Blog. Continue reading “Making Your Website Accessible Part 3: Content WCAG Compliance”
The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.
As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.
I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.
I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).
In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.
- General Guidelines on ‘Writing for the Web’
- Using WordPress to Make Content Accessible (to come in a future post)
To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.
Making Staff Responsible
I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:
Page Ownership Responsibilities
While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:
- Content is up to date
- Content, especially audio/visual, conform to Accessibility Guidelines
- Copyright is cleared for all content (if applicable)
- Transferring ownership when needed (long term leave, end of term)
Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.
We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.
We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.
So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.
Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.
So as part of the website redesign and working on making the site WCAG compliant, I wrote a couple sets of guidelines. One of them was on writing content for the web. Some of the points and the example I got from a coworkers, but most of it I just consider sensible advice. Overall, I tried to keep it fairly short and simple in the hopes that staff members will actually read it!
Writing for the Web
Web readers skim pages and look for keywords, links, and other information that will help them find what they’re looking for quickly. Therefore, when writing new or revising content:
1. Be Clear and Concise
- Make your page title descriptive and concise, keeping it fairly short.
- Keep sentences, paragraphs, lists, and other information short and simple.
- Use lists wherever appropriate, especially when users have choices. Use numbered lists for complex instructions and include important screenshots.
- Unless you’re creating a policy page, keep the entire page short (e.g. 2-3 screens worth).
To find information on citation styles, go to the Library’s Home Page, click on Research Help, then click on Citations and Style Guides and choose APA Style Page, MLA Style page or RefWorks.
For more information about citation styles, check the
- APA Style Page
- MLA Style Page or
2. Speak to Your Audience
- Avoid acronyms and “library” vocabulary when writing content for the library’s webpages.
- Write at a Grade 7-8 level in a direct voice, using “you”. For example, use “get” not “obtain”.
- Because users scan pages and don’t read them, information needs to be written clearly and concisely and at a reading level that doesn’t impede typical user behaviour.
3. Be Meaningful
- Links, in particular, should be meaningful. The words of a link should tell your reader what the link is about.
- Screen readers have the option of listing all of the links on a page, so think about whether a user would know what your links refer to out of context.
- In addition, don’t overuse links. Only use them where it makes sense, such as for a list of resources.
Hopefully this post does not sound like just a rant as I admit that this post has come up from my frustrations from using other people’s work, but I think this is particularly symptomatic of areas where there are not always IT experts, as is the case with many libraries. I also do not boast that I always know what I’m doing, but that’s why I think it’s invaluable to have some kind of code review process.
Making it Simple
As a general rule, better to make things as simple as possible rather than using complex methods if they both achieve the same things. I’ve been told that simple and clean code is the best kind of code.
There may be efficiency concerns involved, but then that seems to be left behind in the cases I’m talking about anyway. (Case in point, our website had 5+ CSS files, not all which had clear purposes, many of which were overwriting each other’s classes, which I had to rework into two files.)
Document and Comment
While some of the simple things might be obvious and self-explanatory, I don’t think I’ve ever seen anything over documented/commented in the ‘real world’ (as opposed to school work), so more is (generally) better. I think it’s doubly important where the creation of a product/tool might be outsourced, but the maintenance of it is done in house (as frequently seems to happen), that the code can be understood by a new/beginner programmer-type person.
Too often I have looked at code recently and thought “what does this do?” or “how many pages does it affect?” While I admit that it’s not always easy to know what or how much needs to be documented, because you don’t always know who will look at it in the future and things you write yourself tend to make sense, but do at least a minimal amount of documentation and commenting.
On a side note, do not name files or functions after yourself (one former student’s name is now unforgettable for that reason and this was created months before I started).
Ideally, there is someone who is an actual programmer on your team or in your unit who you can ask to take at least a quick look over what you’ve done and give you feedback on whether you’ve done it correctly. If there’s no one ‘inside’, consider asking someone on the ‘outside’.
Within a team or unit, if there is more than one programmer-savvy person, consider establishing a Review/Feedback step in the process as you typically see before code commits (if this doesn’t already exist of course).
If you really can’t get feedback from someone else, then much like editing your own writing, step back from it (for, preferably, a couple of days) and look at it with fresh eyes and ask yourself some of the important questions, but namely:
would someone else be able to step in and easily understand what your code does?
I believe that all the above points apply when working with students too. It’s okay if you’re not a programmer. At least take a brief look at the code, see if commenting is done, ask about the general process/framework, ask if they think a beginner programmer would be able to understand their code easily, etc. If you ask, it will at least make him/her think about it!
The end product does not mean it is what you want. Other people also need to be able to maintain and customize/modify. This all seems so obvious, but I think it bears reminding sometimes.
This week, I started creating a WordPress theme for our website, and in doing so, spent a lot of time reading on making a website accessible for persons with disabilities. While we do have legislation stating that all university websites need to be accessible by next year (?) (Accessibility for Ontarians with Disabilities Act (AODA)), our university and library take pride in being accessible. For some reason though, our website is not all that accessible.
Web Content Accessibility Guidelines
Now on version 2.0, most government and public organizations are being held accountable in being compliant with the Web Content Accessibility Guidelines (WCAG). The guidelines divides up the requirements into three levels: A, AA, AAA. While the guidelines themselves are a little hard to decipher, w3 provides a customizable quick reference to break the guidelines down into a more readable document.
When it comes to the general design of the website, it’s actually fairly simple.
- Order and use of elements should make sense even in text only (1.3)
- Minimum contrast (1.4.3)
- Text resize up to 200% in the browser without lost functionality (1.4.4)
- Keyboard accessible and easy to navigate (2.1, 2.4.1, 2.4.5) – have different ways to get to your content
- Make your site predictable (3.2)
- Provide error identification, suggestions, and instructions (3.3)
- Make it compatible with assistive technologies (4.1)
The Difficult Part: Making A/V Content Accessible
I don’t think a lot of people realize that designing a website to be accessible is not the hard part. The hard part in an organization is making sure that the content posted on the website is accessible. In particular, audio/visual elements should have text alternatives, whether that be closed captions, alt text or transcripts.
In order to ensure that content is also accessible, web developers need to work with other staff whether inside their own department or in the greater institution to educate staff who are creating content, because even something as simple as images need text alternatives.
At a college or university, best to contact the accessibility centre/unit on campus to work with them. They might already have the tools or know-how to make a/v content accessible.
Making a WordPress Accessible Theme
So, why reinvent the wheel? That’s what I thought anyway, but there are some issues with using an existing theme and modifying it. I wanted one that was in HTML5/CSS3, and then I later discovered that it should also be using the WordPress Settings API (which was difficult because it was only added in 2.7 so not everyone is using it).
Long story short, I didn’t find any, but then in looking through the files, it turns out the built-in/sample WordPress theme TwentyEleven fits all of these requirements! They do not tout that the theme is accessible, but many of the elements are present in the theme.
I will be posting more once the theme is done (or mostly done anyway) with more details on any changes I will have to make, but I’m thinking they will be very few if any.
A Few Tools
You can find a rather extensive list of tools for evaluating accessibility on the w3c website, but one of the most useful I found was: WAVE, which provides different views of a webpage with alerts and errors (there is also a browser plugin version). There are also a number of good colour contrast checkers browser plugins.