WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Apr 17, 2013 5:10PM

I did want to clarify one thing, it is possible, in JAWS 14 at least, to use
aria-labelledby in combination with role="region" to surround an entire
content region with a label text that is present elsewhere on the page.

However, this would not be good for extended content, such as a paragraph,
since this text would not only be announced at the beginning but also at the
end of the content, and is only good for denoting the boundaries of a given
region with label text.



----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Wednesday, April 17, 2013 1:08 PM
Subject: Re: [WebAIM] Value and prioritization of large-scale things a
website can do for improved accessibility


> aria-labelledby cannot be used for this purpose.
>
> E.G
>
> <p aria-labelledby="anotherParagraph">
> Content
> </p>
> <p id="anotherParagraph">
> Some other content
> </p>
>
> ARIA should not be used all over the place just because it's ARIA, this
> will
> introduce accessibility issues for screen reader users, especially when
> the
> ARIA attributes being introduced are not being applied by those who aren't
> familiar with the ARIA specification or with how these attributes effect
> screen reader behavior.
>
> E.G
>
> <ul class="menu">
> <li role="option">
> Menu item one
> </li>
> <li role="option">
> Menu item two
> </li>
> </ul>
>
> This is an incorrect usage of ARIA that confuses screen reader feedback
> and
> provides no value for screen reader users. Nevertheless I've seen this
> done
> recently on enterprise software that is being pushed out to thousands of
> businesses.
>
> ARIA should not be used without a clear understanding of what is being
> used
> and why.
>
>
> ----- Original Message -----
> From: "Dave Merrill" < <EMAIL REMOVED> >
> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
> Sent: Wednesday, April 17, 2013 12:21 PM
> Subject: Re: [WebAIM] Value and prioritization of large-scale things a web
> site can do for improved accessibility
>
>
>> 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
>> >> >> >
> > >