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: Dave Merrill
Date: Apr 18, 2013 8:12AM

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
> >>>> >>> > >>>> >>> > >>>> >>> 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
> >>> > >>> > >>> > >>
> >> > >> > >> > >
> > > > > > >
> > > >



--
Dave Merrill