E-mail List Archives
Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
From: Bryan Garaventa
Date: Apr 17, 2013 11:54PM
- Next message: Jacek Zadrożny: "Re: Making A Better CAPTCHA For the Visually Impaired And Making Captions More Available To The Hearing Impaired"
- Previous message: Elle: "Re: Making A Better CAPTCHA For the Visually Impaired And Making Captions More Available To The Hearing Impaired"
- Next message in Thread: Elle: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message in Thread: Bryan Garaventa: "Re: Value and prioritization of large-scale things a website can do for improved accessibility"
- View all messages in this Thread
I don't mean to sound hard about this; I'm sorry if what I've written before
sounds this way.
Literally every day, I see examples of how incorrectly implemented ARIA
causes accessibility issues for screen reader users. I'm actually a huge
supporter of ARIA, but there must be a systematic approach to implementing
it, that involves a combination of both adherence to the widget types that
it applies to, and screen reader testing to ensure that the implementation
is properly supported.
In the vast majority of cases where I see this breakdown occur, is when ARIA
is perceived as a magic bullet, where adding the attributes is seen as a
means for making things accessible. ARIA cannot 'make things accessible'
however, and this is very important.
With regard to interactive widgets for example, if the scripting doesn't
exactly match the applied ARIA attributes, and the browser doesn't exactly
support the ARIA implementation, or if the screen reader doesn't
specifically support the implementation, the widget will not work as
intended.
Granted, support will increase in time. However if the ARIA implantation is
coded incorrectly, it will likely never be properly supported.
What I'm trying to say here, is that ARIA is not a fix-all, and it should
not be liberally thrown into pages without a systematic approach to
determine both current levels of support and practical accessibility at the
same time.
----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Wednesday, April 17, 2013 4:10 PM
Subject: Re: [WebAIM] Value and prioritization of large-scale things
awebsite can do for improved accessibility
>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
>>>> >
>>>> >
- Next message: Jacek Zadrożny: "Re: Making A Better CAPTCHA For the Visually Impaired And Making Captions More Available To The Hearing Impaired"
- Previous message: Elle: "Re: Making A Better CAPTCHA For the Visually Impaired And Making Captions More Available To The Hearing Impaired"
- Next message in Thread: Elle: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message in Thread: Bryan Garaventa: "Re: Value and prioritization of large-scale things a website can do for improved accessibility"
- View all messages in this Thread