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: Elle
Date: Apr 18, 2013 6:52AM

Bryan:

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

Dave, I think this point cannot be overstated. If you are looking to
provide more accessibility support for screen reader users only, then I
would follow Bryan's advice on the judicious use of ARIA. But, as he said,
it's not a magic bullet. If you are looking to support a more universally
accessible experience for all users, then I think you should look first to
implement the infinitely less sexy but much more critical basics in your
CMS:


- *Keyboard accessibility:* Ensure that your pages are built using a
progressive enhancement approach, with both valid code and unobtrusive
JavaScript. Test each template to ensure that users can get in (and get
out) of any interaction.

- *Use what works:* I know that sounds obvious, but you'd be surprised
how often hubris gets the better of bright but inexperienced developers.
When in doubt, especially with regards to more interactive elements, look
to incorporate tested and verified accessible solutions instead of rolling
your own. There are several very talented minds here who spend hours every
day solving these problems, and many of them can provide examples of
accessible widgets, sliders, date pickers, etc. that you can use in your
templates.

- *Color contrast:* In whatever default CSS that your CMS ships with,
and along with any user guides or documentation, follow WCAG
rules<http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html>;regarding
appropriate color contrast, and test
with a good tool
<http://snook.ca/technical/colour_contrast/colour.html>;to ensure that
you've hit the mark.

- *Document structure:* Have one. :) I will let everyone else discuss
HTML5 headings, landmarks, and the finer points of how best to ensure that
you have a semantically structured web page. Aim for the most usable
solution, and require your end-users to follow that.


Those are the top four things I would suggest.


Cheers,
Elle

If you want to build a ship, don't drum up the people to gather wood,
divide the work, and give orders. Instead, teach them to yearn for the vast
and endless sea.
- Antoine De Saint-Exupéry, The Little Prince


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