WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Value and prioritization of large-scale things a web site can do for improved accessibility

for

From: Steve Green
Date: Apr 17, 2013 11:59AM

Those survey results correspond with our experience of user testing but I would add one more category of blocker, which is dynamic content (hide/reveal, tabbed interfaces, lightboxes, carousels etc). ARIA markup could help with that, but it is usually going to be specific to widgets rather than being in a template.

I don't think that your example of adding ARIA markup to static content is going to help anyone.

Steve

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Dave Merrill
Sent: 17 April 2013 18:27
To: WebAIM Discussion List
Subject: Re: [WebAIM] Value and prioritization of large-scale things a web site can do for improved accessibility

Steve, thanks very much for taking the time to weigh in here, I appreciate it, very useful feedback.

Re other ARIA markup, if you have a heading as the first item inside a semantic container, is there any point to linking the two explicitly with aria-labelledby on the container pointing to the heading?

The most recent screen reader users survey shows one real-world perspective:
- Headings are by far the most used in-page navigation
- Most reader users are now aware or ARIA landmarks but usage frequency is quite varied
- The most-reported accessibility blockers are inaccessible Flash and CAPTCHA, not information discovery

That survey is here (which I'm sure you all know):
http://webaim.org/projects/screenreadersurvey4/


On Wed, Apr 17, 2013 at 12:51 PM, Steve Green < <EMAIL REMOVED> > wrote:

> To take your points in order, my opinion would be:
>
> 1. Yes, use HTML5 semantic elements. That is already useful and will
> become increasingly so.
> 2. ARIA landmark roles can be useful so they are worth adding.
> 3. Other ARIA markup is likely to be less useful, especially in
> generic templates. Given that there is a cost to everything, I see
> this as a low priority.
> 4. Title attributes on links only add value if they are different from
> the anchor text and provide necessary additional information. That is
> rarely going to be the case in templates. Unnecessary tooltips have an
> adverse effect on some users, so that has to be balanced against the
> benefit of providing them. This is one of many cases where an
> accessibility feature is not necessarily either beneficial or neutral.
> 5. Set the title attribute for content containers would be a definite
> No for me. It would particularly impact screen magnifier users because
> the tooltips are proportionately larger than usual and a tooltip would
> always be present no matter where the mouse is moved.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto:
> <EMAIL REMOVED> ] On Behalf Of Dave Merrill
> Sent: 17 April 2013 16:55
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Value and prioritization of large-scale things a web
> site can do for improved accessibility
>
> Hi folks, first post, hope it's not unwelcome-ly long or obvious. By
> way of intro, I'm a developer at a web software company, not an
> accessibility expert. I've recently gotten interested in
> accessibility, and if there are things we can do to improve access,
> without a lot of complexity either for us to build or for our users to user, I may be able to get some of that in.
>
> By "large-scale", I mean page structure changes that can be done on
> the site's main templates, rather than hand-tweaked changes to each
> page. For example, the one step of applying ARIA landmark roles is in
> reach for many sites, just by updating their blog or content
> management software templates. Doing the whole nine yards to annotate
> every widget's interaction state is much harder, unless the underlying
> platform already does it.
>
> Here are some possible steps a site could take, that are all
> relatively low-hanging fruit:
>
> - Place all content within HTML5 semantic container tags, specifically
> article, aside ,nav, section, figure, figcaption, footer, header, and
> main
> - Assign ARIA landmark roles to content containers and HTML headings
> - Assign aria-label, aria-labelledby and aria-describedby attributes
> to appropriate content containers
> - Set the title attribute on links
> - Set the title attribute for content containers (less desirable,
> since it's seen by all, and containers aren't typically labelled this
> way)
>
> Which of those would you say are worth doing? Taken together, would
> they make a real difference in accessibility? Are there other simple
> things that could be done, ideally the page template level, rather
> than specific hand tweaks for every page?
>
> (I'm specifically not talking about forms or interactivity, that's a
> whole other topic. I'm also not talking about making sure HTML and
> image colors have good contrast, not because it's unimportant, but
> because it has to be done on a case-by-case basic, rather than in
> global templates.)
>
> Thanks in advance for any thoughts,
>
> Dave Merrill
> > > list messages to <EMAIL REMOVED>
> > > list messages to <EMAIL REMOVED>
>



--
Dave Merrill