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: Humbert, Joseph A
Date: Apr 17, 2013 1:59PM

The biggest problem I have tested (and left out in my first email ) is that JAWS 14 in IE9 and Firefox 20 relates incorrect heading levels for correctly coded HTML Headings in HTML5 Elements.

Coded structure:
<h1>Explicitly Ranked Headings</h1>
<nav>
<h2>Navigation</h2>
</nav>
<section>
<h2>Section</h2>
<article>
<h3>Article</h3>
<section>
<h4>Subsection</h4>
</section>
</article>
</section>
<aside>
<h2>Aside</h2>
</aside>

JAWS Heading List (FF20):
h1. Explicitly Ranked Headings
h3. Navigation
h3. Section
h5. Article
h2. Subsection
h3. Aside

Only difference between IE 9 and Firefox 20 is IE 9 drops out the h2. Subsection entirely.

So my advice would be to include the capabilities in your system, but include verbose documentation as to the current pitfalls.

- Joe


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

Thanks Joe.

The coexistence of explicit heading levels and a nested container hierarchy definitely is messy, no question. I hope that doesn't mean semantic containers can't ever be used though.

Do you think the use of h1 at every level, like some examples in the standard, is the cause of the reader problems you see? I personally don't expect real sites to do that, standards or not, because the css required to style nested headings appropriately is prohibitively verbose and inefficient. If heading levels are appropriate for their location within the semantic hierarchy, does that work reliably?

Ultimately, from my perch at a CMS vendor, these decisions are really our customers' to make. So far, it seem right to me that we provide tools for semantic containers, headings, ARIA landmarks, and possibly some ARIA labeling and let each site planner decide what their strategy will be. Tomorrow's usual may not be the same as today's.


On Wed, Apr 17, 2013 at 2:06 PM, Humbert, Joseph A < <EMAIL REMOVED> >wrote:

> Hi All,
>
> I would say No to:
>
> "Place all content within HTML5 semantic container tags, specifically
> article, aside ,nav, section, figure, figcaption, footer, header, and main"
>
> Because the HTML5 outline algorithm (
> http://dev.w3.org/html5/spec/sections.html#outlines) is not supported
> by all adaptive technology and Web browser combinations. Therefore,
> if you use the sematic tags you will end up with an incorrect heading
> structure in some cases and not others. I just tested with JAWS 14,
> NVDA 2013, Voiceover on IE9, FF 20, Safari 5. NVDA and Voiceover both had issues. Thankx.
>
> Reference:
>
> http://www.accessibleculture.org/articles/2011/10/jaws-ie-and-headings
> -in-html5/
> http://html5accessibility.com/
>
> Joe Humbert, Accessibility Specialist
> UITS Adaptive Technology and Accessibility Centers Indiana University,
> Indianapolis and Bloomington
> 535 W Michigan St. IT214 E
> Indianapolis, IN 46202
> Office Phone: (317) 274-4378
> Cell Phone: (317) 644-6824
> <EMAIL REMOVED>
> http://iuadapts.Indiana.edu/
> -----Original Message-----
> From: <EMAIL REMOVED> [mailto:
> <EMAIL REMOVED> ] On Behalf Of Detlev Fischer
> Sent: Wednesday, April 17, 2013 1:49 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Value and prioritization of large-scale things a
> web site can do for improved accessibility
>
> Hi Dave,
>
> One thing not on your list I would throw in because it makes a big
> difference to keyboard users AND will be relatively easy to implement
> via
> CSS: making sure that you have always have good visibility of current
> keyboard focus on interactive elements when tabbing through content.
> From my experience of testing sites, even on sites with decent overall
> focus visibility, I often find areas where the focus is difficult to see.
>
> Best, Detlev
>
> On 17 Apr 2013, at 19:27, Dave Merrill wrote:
>
> > 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
> > > > > > list messages to <EMAIL REMOVED>
>
> --
> Detlev Fischer
> testkreis - das Accessibility-Team von feld.wald.wiese c/o
> feld.wald.wiese Thedestraße 2
> 22767 Hamburg
>
> Tel +49 (0)40 439 10 68-3
> Mobil +49 (0)1577 170 73 84
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
>
>
> > > list messages to <EMAIL REMOVED>
> > > list messages to <EMAIL REMOVED>
>



--
Dave Merrill