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 2:00PM

P.S. titles are really only useful when they are the webpage title or
the title of frames/iFrames (titles for frames/iframes are required
and announced by all A.T. as far as I know).
.. other titles, such as on links, buttons etc. are read
inconsistently, often not at all, by screen readers.


On 4/17/13, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> 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
>>> >
>>> >