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: Birkir R. Gunnarsson
Date: Apr 17, 2013 1:59PM

A few thoughts:
It is important that webpage title be descriptive and that webpage
language be explictly set in its head section.
Is this something you could prompt your customers to do when creating
a new page from a template?
Page title should indicate subpage | site in my opinion, for instance
Inbox | GMail
(or vice versa).
Page title is the first thing most screen readers read automatically
when a page is loaded.
Page language is generally not a big problem for people in the U.S.
but in Europe there is a lot of French, German or Danish screen
readers, for instance, that may start reading a website with the wrong
speech synthesizer if it is not aware of its language.

For landmarks and html5 elements (which many screen readers are not
sure how to deal with yet, and do so by treating them like landmarks),
make sure they are not over used.
Screen readers offer users navigation keys to jump to next or previous
landmark (; and shift-; in Jaws, d and shift-d in NVDA for instance).
You can also list all the landmarks on a webpage, though I usually do not do it.

I am beginning to see a lot of site that throw in the section and
article elements very generously, making the landmarks a lot less
useful and creating a lot of noise.
Imagine a news article site with 20 headlines, when each of them s
wrapped inside an Article tag, evenif it is just a link with possible
2 lines of text, these are all treated and announced as article
regions by some screen readers. Sections are just announced as regions
by Jaws at least.

so if we had
<code>
<section>

<article>
<h2>my headline text</h2>
</article>
</section
</code>
...
Jaws would respond this way when pressing the ; key.

region
article
...

It also announces these for users who are navigating the page by
pressing the arrow down key in thir virtual buffer.


Assume you had this markup for every news headline with a line of text
on the site and you may end up with 30 to 50 aria landmarks on a
webpage, making them useless as a structural markup and adding 30 to
50 lines containing the single word "region" or "article" to users who
are slow or want to inspect the site with arrow keys only, making the
site very cumbersome and content hard to get to.

Each page should have one MAIN aria landmark.
Banner should be the landmark around the header content.
contentinfo should mark the footer content
A navigation landmark is useful for navigation menus on the site. I
personally often recommend to add an aria-label to a navigation
landmark when you have multiple navigation menus on a site.

Global navigation (your standard menu on all pages)

My actions (if user is logged in and can perform certain actions only
when logged in).

etc.

I still recommend using div over section, until screen readers better
know how to treat sections, at least be careful and use section
according to spec.

I have recommended that the article tag be used no more than once on a
site, i.e. the article element is useful when user loads a site with
one article (more than 5 lines of contiguous text).

Imagine if you put an h1 heading for the article inside an article tag
inside a main tag (because it is the main content of the page).

<code>
<main role="main">
<article>
<h1>My headline</h1>
</artile>
</main>
</code>
Again Jaws will announce
main
article
heading level 1 my headline text
If you use an arrow key to explore the site you will hear "main"
"article" "headinglevel 1 text".

Here, if the article is marked up as the only h1 heading on the site,
the landmarks add nothing of value but unnecessary noise, especially
when you throw the main and the article landmark together.

It would be useful to add required or aria=required="true" to form fields.
Again, I am just giving examples of the problems. It is hard to come
up with one-size-fits-all rules for these things.

Hope you find some of these thoughts useful.
-B

On 4/17/13, Dave Merrill < <EMAIL REMOVED> > wrote:
> Paul, is aria-labelledby a good way to say that the description for some
> static content is in some other container elsewhere?
>
> Here's what I'm thinking: Our software make a distinction between content
> contributors and template designers. Contributors are subject-matter
> experts and/or public-facing marketers, who quite likely don't know about
> ARIA, or even much HTML. My thought was that ARIA attributes, like
> container creation and choice of container element type, were in
> designer-land, not content-land. From that standpoint, it would be better
> if template designers could effectively say, "announce this using the
> content from that paragraph over there", which a contributor would write,
> rather than making the designer responsible for that labeling themselves.
>
> Am I being clear? Would aria-labelledby provide that indirection
> appropriately, for static content?
>
>
> On Wed, Apr 17, 2013 at 3:02 PM, Paul J. Adam < <EMAIL REMOVED> > wrote:
>
>> Mark up your HTML5 sections with WAI-ARIA Landmark roles and give them an
>> aria-label, i.e. <nav role="navigation" aria-label="Navigation">. The
>> aria-label should be announced as the accessible name for that container.
>>
>> Don't limit ARIA to just dynamic content, role=button is great for faux
>> button elements, aria-required=true great for required fields.
>>
>> If you're planning for the future WAI-ARIA support will only grow and
>> become more consistent just like HTML5 and CSS3.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>> On Apr 17, 2013, at 1:54 PM, Steve Green < <EMAIL REMOVED> >
>> wrote:
>>
>> > I think that landmarks are fine but ARIA is primarily intended for
>> dynamic content. There comes a point when adding more semantic markup
>> actually starts to reduce the accessibility because the 'noise' gets in
>> the
>> way of the content. I would therefore reserve the use of ARIA for dynamic
>> content, and even then only when it is actually needed. Some
>> well-designed
>> dynamic content does not need it.
>> >
>> > I think there is already an obvious implicit relationship between a
>> heading and its container, and that aria-labelledby is really intended
>> for
>> use where relationships are not obvious or implicit.
>> >
>> > Steve
>> >
>> > -----Original Message-----
>> > From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Dave Merrill
>> > Sent: 17 April 2013 19:20
>> > To: WebAIM Discussion List
>> > Subject: Re: [WebAIM] Value and prioritization of large-scale things a
>> web site can do for improved accessibility
>> >
>> > Steve, are you saying that ARIA landmarks on static content aren't
>> useful in general, or just that it's not necessary to link a heading to
>> the
>> parent container whose content it describes? I assume the second, just
>> making sure I'm not misinterpreting you.
>> >
>> > I hear you about dynamic content. Our customers have to prioritize
>> whizbang vs accessibility to some degree, and how they do that is really
>> out of our hands. In the future, it would be great if we could include a
>> set of styleable and accessible widgets they could use, but for now I
>> need
>> to focus on page structure tools, as I've said. In any case, many sites
>> value supposed uniqueness so highly that they'll find some shiny new toys
>> to sprinkle around anyway.
>> >
>> >
>> > On Wed, Apr 17, 2013 at 1:59 PM, Steve Green <
>> <EMAIL REMOVED>
>> >> wrote:
>> >
>> >> 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
>> >> >> >> >> >> list messages to <EMAIL REMOVED>
>> >> >> >> >> >> list messages to <EMAIL REMOVED>
>> >>
>> >
>> >
>> >
>> > --
>> > Dave Merrill
>> > >> > >> messages to <EMAIL REMOVED>
>> > >> > >> > >>
>> >> >> >>
>
>
>
> --
> Dave Merrill
> > > >