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
>> >>>> >
>> >>>> > -----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
>> >>>> >>> >> >>>> >>> >> >>>> >>> http://list.webaim.org/Address
>> >>>> >>> list messages to <EMAIL REMOVED>
>> >>>> >>> >> >>>> >>> >> >>>> >>> http://list.webaim.org/Address
>> >>>> >>> list messages to <EMAIL REMOVED>
>> >>>> >>>
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> --
>> >>>> >> Dave Merrill
>> >>>> >> >> >>>> >> >> >>>> >> Address
>> >>>> >> list messages to <EMAIL REMOVED>
>> >>>> >> >> >>>> >> >> >>>> >> Address
>> >>>> >> list messages to <EMAIL REMOVED>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Dave Merrill
>> >>>> > >> >>>> > >> >>>> > list
>> >>>> messages to <EMAIL REMOVED>
>> >>>> > >> >>>> > >> >>>> > >> >>>>
>> >>>> >> >>>> >> >>>> >> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Dave Merrill
>> >>> >> >>> >> >>> >> >>
>> >> >> >> >> >> >> >
>> > >> > >> > >>
>> >> >> >>
>
>
>
> --
> Dave Merrill
> > >