E-mail List Archives
Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
From: Elle
Date: Apr 19, 2013 5:51AM
- Next message: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Next message in Thread: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message in Thread: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- View all messages in this Thread
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
> > >> >>>> >
> > >> >>>> >
- Next message: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Next message in Thread: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- Previous message in Thread: Dave Merrill: "Re: Value and prioritization of large-scale things awebsite can do for improved accessibility"
- View all messages in this Thread