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
>>> >
>>> > -----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
>>> > >>> > >>> > list
>>> messages to <EMAIL REMOVED>
>>> > >>> > >>> > >>>
>>> >>> >>> >>>
>>
>>
>>
>> --
>> Dave Merrill
>> >> >> >>
>