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 19, 2013 6:37AM

Thanks Elle, I'll keep that resource in mind.

Primarily though, we don't provide templates we expect customers to use,
because they won't. We provide tools for customers to build their own, as
appropriate for their site. The issue here is whether we provide fields to
attach ARIA metadata to content containers, and render it appropriately in
our default output.

As I've said, adding landmark roles is very easy for me to do. The problem
is that once we bring up accessibility, as I understand it, the interaction
between the multiple layers of information outline gets hard to understand,
and the effectiveness of any particular implementation varies across
readers. Overall, it seems to require more education and effort than we
expect most of our customer base to put into accessibility. We couldn't
come up with interface concepts to make this level of accessibility easy
and relatively foolproof, so we thought it better not to broach the
subject, and let those interested enough to learn about proper application
and testing apply these techniques at the full-custom level of our product.

If you or others here have ideas on how we could make this process clearer
for naive users, I'd be happy to listen; I suspect it may not really be
possible though. Unfortunately, even though I expect that many of you are
in this as a business as well as out of personal commitment, my interest is
at this point mine alone, so I can't hire you to advise. If I have a clear
proposal with demonstrable value that's not too difficult to build, I can
present it upstream and quite possibly get it in, as I was trying to do.
I'd be happy to discuss further ideas with anyone who's interested, here on
this list, offline in private email, or in person (Boston area). Hopefully
I've given a general outline of the kind of solution that could work.

Dave Merrill


On Fri, Apr 19, 2013 at 7:51 AM, Elle < <EMAIL REMOVED> > wrote:

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



--
Dave Merrill