Mackey

Website Accessibility – It’s the law, it’s moral and it’ll make your site better!

by

Website Accessibility – It’s the law, it’s moral and it’ll make your site better!

Honestly, we never thought we would become accessibility experts (well, maybe not experts, but at least well schooled). We didn’t pay much attention to accessibility. Of course, we were cognisant of the SEO benefits of making sure your headings are in order and that you have alt tags on all your images — but if it didn’t increase the bottom line, we weren’t worried about it.

Oh, were we wrong.

Looking back at our ignorance, I can’t help but feel ashamed — it doesn’t take much extra effort to make a website accessible, but it can make a world of difference to someone with disabilities.

When we started working with education, accessibility was (and is) the buzzword. Everyone is getting sued or in fear of being sued over accessibility. And tt’s even started to go beyond government-funded organizations — lawyers are advising businesses that they could be next!  Now, I don’t think the legal attention is necessarily because the suing lawyers want to create a better internet for disabled people, but nonetheless, it has brought a topic to the forefront that we as designers, developers, and content creators should all be aware of and helping to make a difference.

So, regardless of motive, we began to focus on making a website accessible, but only from the standpoint of passing the WAVE Accessibility Tool (and of course SEO).  During the development of the Pasadena City College website we were lucky enough to 1. have the legal spotlight upon higher education, 2. have direct access to students and staff with disabilities, 3. have a team that believed in accessibility (yes, that’s you Michael Ihrig) and 4. the support of executives to spend the time and resources to get accessibility right — testing with actual disabled students and staff, hearing their feedback, making adjustments and retesting (passing WAVE was just a bonus!).

For me it hit home the first day we did user testing. I can remember sitting in the office, watching a blind employee trying to navigate what we thought was an accessible site (what WAVE thought was an accessible site too!). It wasn’t the headings, it wasn’t the navigation — it was the things that you can’t test with an automated tool…

  • The alt tag that reads “this is a picture of a student” — that’s worst than putting no alt tag!
  • A button with “Click here” with no clear text of where they will go if they “Click Here.”
  • Not being able to find the main navigation, the section navigation, etc.

It was the small things, the things we take for granted. For the first time, I was able to l experience the web the same way as someone who can’t see. From that, we have learned some valuable lessons and some simple things you can do to make life on the web a little better for people with disabilities.

ARIA

With HTML5 came ARIA or Accessible Rich Internet Applications. ARIA gives you the ability to add tags directly in your markup that speak directly to people using assistive technology — allowing you to cater and customize the experience for people using screen readers and other assistive technology. You can read the full W3C Recommendation here. We can’t possibly cover every ARIA feature (60+, see all), but here are few keys aspects that we found really helped.

Roles

Roles helps identify aspects of the page for users using screen readers. Users that cannot see the visual layout of the page, need roles to help them understand and navigate to aspects of the page. There are a lot of role categories, but they are broken down into four major buckets:

  1. Abstract Roles
  2. Widget Roles
  3. Document Roles
  4. Landmark Roles

Roles can be thought of like categories. Labels (see below) help define and identify the role. You can role and label everything, but we found through testing that the most important roles to pay attention to were Landmark Roles and Widget Roles (the others are important as well, but with limited resources, we needed to focus on the greatest ROI).

Landmark Roles

Landmark Roles are a bucket of roles used for navigational structures. We usually have more than one navigation menu on a site and using Landmark Roles in conjunction with labels allows you to indicate to someone using a screen reader which navigation is which and allows the user to quickly jump to navigation.

In it’s simplest form, you would add a role=”navigation” and aria-label=”Main Navigation”  to the wrapper of your navigational element.

<div role="navigation" aria-label="Sticky Utility Navigation">...</div>

Widget Roles

Widget Roles are things like tabs, scrollbars, tooltips, buttons, etc. — they help give context to the user about the element they are interacting with.

<div id="accordion-d11e519" role="tablist" aria-multiselectable="true">

    <a role="button" data-toggle="collapse" data-parent="accordion-d11e519" href="#d11e519-collapse-1" aria-expanded="false" aria-controls="d11e519-collapse-1">General Questions</a>

</div>

You can view all roles at https://www.w3.org/TR/wai-aria/roles#abstract_roles.

Labels

ARIA labels help identify elements that are invisible to a screen reader. Use labels to provide an invisible label (visible to screen readers) when a visible label cannot be used. This can be for buttons, input fields, text areas, etc.

For example, you might have a modal that is closeable via an image or a Font Awesome icon. To a screen reader, this means nothing. By adding the aria-label attribute you can tell a screen reader that the button is a button to close the modal.

<button aria-label="Close" class="close-button">X</button>

Additionally, if you have multiple labels that need to be grouped, you can use aria-labeled-by attribute on the parent element. For example:

<div role="group" aria-labelledby="groupLabel">
  <span id="groupLabel>Work Phone</span>
  +<input type="number" aria-label="country code">
  <input type="number" aria-label="area code">
  <input type="number" aria-label="subscriber number">
</div>

Visit https://www.w3.org/TR/WCAG20-TECHS/ARIA14.html for more information about ARIA labels.

Hidden

When you add aria-hidden=”true” to an element, it and all its descendants will be hidden from screen readers. This is really helpful if you need to hide content from screen readers, but want to display the content to users NOT using screen readers without having to change visibility.

<div aria-hidden="true">Screen reader will not read this.</div>

Screen Reader Only Classes

In many instances you want an element on the page to only be visible to screen readers. For instance, if you’re using a magnifying glass icon as your search navigational element, you will want to spell that out for screen readers — Search. Most CSS frameworks will come with a screen reader only class.

We used Bootstrap and their screen reader only class is sr-only. When added to an element, the element will only be visible to screen readers.

<a class="magnifying-glass" href="#open-search-modal"><span class="sr-only">Open Search</span></a>

If you want to create your own class, you can do so and then add the following to your stylesheet (CSS):

.screen-reader-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    border: 0;
}

Modals with Forms

Building off the idea of opening a search modal and including text only visible to a screen reader, when the user clicks to open the modal, the cursor should focus on the input field. Again, using Bootstrap, this can be done via adding a data-target attribute with the id of the input field that should be focused when opening the modal. For instance, data-target=”#search-field.”

<button class="site-search" data-toggle="modal" data-target="#searchModal">
<span class="sr-only">Search PCC</span><span class="fa fa-search"></span>
</button>

Alt Tags

Yes, include them, but if they have no relevant context to someone using assistive technology, then add aria-hidden=”true.” In the example above, we have a photo of a student. There is no added value unless you can see the image, so in this case include aria-hidden=”true.”  If you don’t have the option of adding aria-hidden=”true”  to your images via your CMS, then leave the alt tag value blank, ie alt=”” — this will make screen readers ignore the image without throwing an error (your SEO expert might say this is bad, but for a person using a screen reader, this is just flat out rude.)

<img src="student-image.jpg" alt="A photo of a student at school" aria-hidden="true" />

Nested Headings

Hopefully, this is obvious to you, but all your heading tags should be nested, starting with H1, then H2, H3, etc. There should only be one H1 as it is your page title. Think of it similarly to an outline for an essay or chapters for a book — heading tags tell the user what is in the outline of the webpage as well as allows someone using a screen reader to jump from section to section.

Side note: Be sure to make your headings relevant and make sense. They should indicate the major topics discussed on the page.

Don’t Use All Caps

If you type HELLO WORLD in all caps, screen readers will read that as H-E-L-L-O W-O-R-L-D — each letter, one at a time. If you need to make text uppercase, create a class for uppercase text, ie uppercase and add it to the block of text you want to be uppercase.

.uppercase { text-transform: uppercase; }

Bonus: Making PDFs Accessible

We focused on onsite content, but in higher education, we ran into a large (2000+) amount of PDFs that needed to be accessible. We did not have vast resources to make PDFs accessible, so we needed the participation and buy-in of the school. We took the approach:

  1. Can the PDF be a live page on the site and not be a PDF? If yes, then problem solved. If no…
  2. Educate the user on the need for PDFs to be accessible, then we refer them to the tools to help them make their PDF accessible (and yes sometimes, in simple cases, we did this for them)

PDF Accessibility Boilerplate and Tools:

“Any document posted to the public website must be section 508 compliant. In other words, it needs to be screen-reader accessible. To make PDF documents accessible/ 508 compliant and ready to post to the web, you just need Adobe Acrobat Professional and the attached instructions.

For a single column text-based document it typically takes less than 5 minutes to make that document accessible using the Acrobat Pro Accessibility Checker. For documents with more complex layouts, a lot of images, graphs, and data tables, it can take much longer at first as the learning curve is steeper. But once you’ve learned how to mark an image as “Decorative,” for example, or correct improperly nested headings that had been used incorrectly for styling in a converted Word document, the process becomes fairly straightforward. “

PDF Accessibility Resources:

 

Accessibility is where design, content, and development all come together. You need everyone to be on the same page and need all to help make any site accessible. I encourage you to also read our post, Wrangling Content Through Collaborative Content Workshops to learn how to get buy-in, create useful content, focus on user needs and find success when creating content for large organizations and higher education.