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 19, 2013 5:51AM

Dave:

When the company does choose to consider any template level revisions to
your CMS, I think it might be helpful to see other examples of accessible
templates in use today. One that comes to mind is the Web Experience
Toolkit: http://wet-boew.github.io/wet-boew/demos/index-eng.html


Hope that helps,
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 11:30 PM, Dave Merrill < <EMAIL REMOVED> >wrote:

> Bryan, it's not me who's shut it down, it's a company decision. It would be
> different if we expected technically sophisticated accessibility experts to
> be major users of our software, but realistically, that's not the case.
>
> Based on everything I've heard here and elsewhere, addressing accessibility
> in helpful ways takes more experience and effort than we expect from
> typical content-contributor or template-builder users. The first tool on
> the table was a simple ARIA landmark role dropdown for content containers,
> which I would have liked to provide. However, once you start talking about
> accessibility beyond headings, you hit the issues we've discussed around
> the tricky relationship between semantic container nesting, headings and
> landmarks. We didn't see any way to distill those messy structural concepts
> into user-friendly tools appropriate for our user base.
>
> There's some chance I'll still be able to get landmarks in, since they're
> trivially easy to build, but I doubt it. They're somewhat out of place in
> our context, even though they could be useful in the right hands.
>
> To be honest, the decision to drop this made me sad, unexpectedly so,
> though I understood it.
>
> Dave Merrill
>
>
> On Thu, Apr 18, 2013 at 7:42 PM, Bryan Garaventa <
> <EMAIL REMOVED> > wrote:
>
> > 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
> > >> >>>> > > > >> >>>> > > http://list.webaim.org/Address
> > >> >>>> > list
> > >> >>>> messages to <EMAIL REMOVED>
> > >> >>>> > > > >> >>>> > > > >> >>>> > > > >> >>>>
> > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> --
> > >> >>> Dave Merrill
> > >> >>> > > >> >>> > > >> >>> > > >> >>
> > >> >> > > >> >> > > >> >> > > >> >
> > >> > > > >> > > > >> > > > >>
> > >> > > >> > > >> > > >>
> > >
> > >
> > >
> > > --
> > > Dave Merrill
> > > > > > > > > > >
> > > > > > > >
>
>
>
> --
> Dave Merrill
> > > >