Implementing & Evaluating Web Application Accessibility

Slide Deck

Implementing and Evaluating Web Application Accessibility from 3Play Media

In this webinar, Jared Smith, the Associate Director of WebAIM, will provide an overview of web accessibility. His expertise in the field will leave you with web accessibility tips and strategies that you can implement right away, as well as tools and resources for evaluating your site or web application’s current accessibility.

While awareness of web accessibility is increasing, it can often be an overwhelming thing to implement.

This presentation will cover:

The principles of web accessibility
Accessibility laws and standards
The challenges of making web content accessible
Tips for implementing an accessible website or application
Why you need to test your website for accessibility
Tools for evaluating your site’s current accessibility

Presenters

Jared Smith
Associate Director | WebAIM

Lily Bond (Moderator)
Director of Marketing | 3Play Media

Webinar Q&A: Getting Technical with WebAIM’s Jared Smith

Is there a particular font and font size that you recommend for websites?

JARED SMITH: When it comes to font faces, most good, modern research tends to show that it doesn’t matter a whole lot when it comes to accessibility, readability, retention, and things like that. So, I don’t think there’s a particular specific recommendation. Just use good font faces that are generally readable to the user.

"10

We see old recommendations of “only use sans serif fonts for print and serif with the hooks and flags,” like Times New Roman for print. Those are really quite dated. With modern displays and resolutions, that doesn’t seem to have much of an impact anymore. So if you build your corporate website with Comic Sans Serif, that may not really impact readability, but it is going to impact perception of the site, which I guess could impact accessibility and usability.

As far as font sizes, I haven’t seen anything specific. Too small? You know it when you see it. But if you want a number, anything less than about 10 pixels tends to become more difficult. That’s what we found in the research we conducted with users that have cognitive disabilities.

What are practical ways that someone, like a developer, can assess the end-user experience and favor the experience over simply meeting compliance? How do you evaluate that?

JARED SMITH: I think that’s kind of what accessibility is about. Much of the difficulty with that question is that the people who are designing, building, and maintaining web content for a particular site are so intimately familiar with that because they built it, that very often it’s difficult to see those usability issues on their site. So, I think user testing [is important].

“Stepping outside of your own experience with a website and doing user testing is probably the most important thing that you can do [in that area]. These are the types of things that can’t be evaluated by a tool or with a checklist.”

I wrote a blog post on our website a few years ago about web accessibility testing, user testing, with people with disabilities. Focusing on that broader user experience, as opposed to simply identifying accessibility issues, may provide some insight there.

Stepping outside of your own experience with a website and doing user testing is probably the most important thing that you can do [in that area]. These are the types of things that can’t be evaluated by a tool or with a checklist.

Where is WebAIM located, and do you provide face-to-face training?

JARED SMITH: We’re located at Utah State University in Northern Utah. And, yes, we do face-to-face training. We can come on site to provide training.

We also host trainings here in Utah four or five times a year. There’s information on the webaim.org site about our training offerings as well as other services that we can provide.

Are people with cognitive disabilities the largest group of those with disabilities, or are blindness and low vision the most common?

JARED SMITH: Those with cognitive and learning disabilities is the largest group, as near as we can tell. It tends to be a little difficult to get really good numbers and statistics about disability, especially with web content and web interaction because you can’t really detect whether a user has a disability on your website. You can detect whether they’re using Internet Explorer or Chrome. But you can’t tell whether they’re using a screen reader or a screen magnifier or if they’re navigating with the keyboard.

Those types of things are difficult. And then I’d ask, even if you could detect that, what would you do? Hopefully, you would still focus on universal accessibility.

While it’s difficult to get good numbers, as near as we can tell, those with cognitive and learning disabilities likely is a larger group than all of the other disability groups put together – larger than those with visual disabilities, hearing disabilities, and motor disabilities put together. Upwards to 20% of the population; I’ve heard numbers that suggest that. So it’s quite significant.

Do you have any good resources for ARIA (Accessible Rich Internet Applications suite) usage?

JARED SMITH: Probably the best resource I would recommend is the ARIA Authoring Practices document. Within it, there’s something called design patterns, and the ARIA design patterns are awesome.

Basically, if you’re building some type of component like a dialog window or a slider or an expanding and collapsing component, you can pick the type of the component or element that you’re building, and it will document it. It will tell you, “This is what this thing is. This is what the keyboard interaction needs to be (that you need to define),” so that a user is interacting with it in the standardized way.

This is the ARIA markup that’s necessary for it to be assessable. And then it also references several examples of those widgets or controls that have already been built, so you can go and look and see how they’re built.

So that’s one good resource. We have a pretty high-level overview of ARIA on the WebAIM site, as well. There are quite a few other examples out there.

Could you talk about the difference between a title and an h1 and how many headings are too many? Should we only use one h1 per page? And wouldn’t one use the title in brackets for the main title and then h1 for top level headings (like Roman numerals in a formal outline)?

JARED SMITH: The title element in HTML will define, essentially, a description for the document itself. That is what shows up in the bar at the top of your browser within the tab. That is what screen readers read when a user comes to that page or if they switch windows or tabs. So, that should be descriptive of the page content.

Download the White Paper:
White Paper: Solving Web Accessibility: Leaving No One Behind

The h1, or first-level heading, has a very similar function (or purpose). Generally, it should define what the page is. They may even be very similar or even identical, the title and the h1. But they’re a little different in how they’re presented and their functionality. And so, even if there is maybe some redundancy between them, a screen reader may even read them twice – once when the user comes to the page and then again when they get to the h1. That’s OK.

The h1 is used to define, within the document itself, what it is, and defines that root level within the outline. We would then define subheadings below those h2s and h3s (and so forth) to do subsections within that.

Again, we do have an article on the WebAIM site. And the question of how many is too many? That will vary based on the complexity of the content.

Any heading is better than no heading at all, if it’s truly a heading. So make sure you’re marking things up as heading. You can have too much of a good thing, but rarely the opposite is the case. We see things that should be headings that are not marked up as headings.

Are there any courses or testing that a developer can take for an official certification in web accessibility?

JARED SMITH: There are a few that are out there for accessibility certification. There’s a relatively new one by the IAAP, the International Association of Accessibility Professionals. As a new organization, they have recently rolled out a certification for developers. I believe the National Federation for the Blind (NFB) also has a developer certification.

So, yeah, there are some out there. The question is really the current value and applicability of those in the field itself because this is a relatively new field. But more than anything, regardless of the certification or which one you go for, gaining that knowledge is really important.

What resources could you provide for low budget companies and organizations to do accessibility compatibility testing?

JARED SMITH: Accessibility is not all that difficult if you follow the guidelines. That idea of accessibility compatibility testing is kind of interesting. When we think about compatibility, I think of it like, “Does it work for this particular browser or this particular screen reader?” And usually, if you follow standards, you don’t have to worry too much about that because the support in the various browsers and assistive technologies is good.

There are a lot free tools out there. But really, when people ask us how much does web accessibility cost, it’s always a factor of knowledge and education. The more you know about accessibility, it just becomes a natural part of what you do. And so, things like this webinar, WebAIM, the great work that 3Play Media is doing, and others helps inform accessibility and makes it much easier.

Are there any accessibility guidelines for mobile devices, cell phones, and tablets, or is it an extension of the general accessibility guidelines for web?

JARED SMITH: For mobile, that is an area that the W3C is working on. There’s an article that talks about the applicability of WCAG 2.0 to mobile that can be insightful. They are looking at updates to WCAG 2.0. They’re starting to define these more concretely.

So, the W3C has some really good resources. For the particular authoring platforms, for iOS or for Android, there is guidance there. There are details on how to implement accessibility in native mobile apps. So that’s also a good resource.

All of that’s a little bit new. As far as technical guidelines and standards, a lot of that is yet to come, regarding official W3C specifications for mobile accessibility. We have to use a lot of other things and extrapolate from those to get to guidance for mobile, as of right now.

Services

Why 3Play?

Learn

Company