WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Apr 18, 2013 5:42PM


I wouldn't shut it down, just express caution. It's a powerful capability,
but unfortunately the number of ways to properly implement it, is only a
tiny fraction of the number of ways it can be improperly applied. It really
does take a good understanding of screen reader behavior and testing to get
everything working correctly.

ARIA regions and landmarks are easier, since they simply group content
containers based on similar characteristics.

I don't mean to be discouraging, just to impress the importance of being
aware of all of the variables involved, which will save you many headaches
later down the road.




----- Original Message -----
From: "Dave Merrill" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Thursday, April 18, 2013 7:12 AM
Subject: Re: [WebAIM] Value and prioritization of large-scale things
awebsite can do for improved accessibility


> It looks like I've been shut down on doing anything with ARIA for now, for
> a combination of reasons. Semantic containers are in, again for a variety
> of reasons; no doubt they'll be used with varying degrees of correctness
> and accessibility.
>
> Thanks very much to all for their thoughts and experiences, great
> community.
>
>
> On Thu, Apr 18, 2013 at 1:54 AM, Bryan Garaventa <
> <EMAIL REMOVED> > wrote:
>
>> 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
>> >>>> >
>> >>>> >