E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Dave Merrill
Date: Mon, May 06 2013 6:43AM
Subject: Value and prioritization of large-scale things awebsite can do for improved accessibility
No previous message | No next message

Just wanted to update anyone watching this thread on progress on getting
improved accessibility features into our CMS product -- there's been a
major change for the better. Thanks very much to everyone here for their
feedback and assistance.

I built out a javascript-based panel of tools to help template and page
authors using our CMS think about the accessibility of their content. As I
hoped might happen when there was something visual to for people here to
see, they understood how tools like this could be helpful, and the panel
has the go-ahead for our next release. This is still a near-zero budget
project, and I'm still doing most of it on my own time, because I want to
make sure it happens, but there's enough buy-in to get these features into
the product.

So far, the tools panel consists of:

- A display of the page outline, as derived from the HTML5 headings and
sections model.

- A listing of any ARIA landmarks

- A listing of all link texts

- A listing of all image alt tags

- A listing of all tables, indicating whether it's likely to be considered
a layout table (no headers), which shouldn't have a summary or a data table
(has headers), which should have one, and a listing of all headers if there
are any. It also indicates where there are row or column spans, which may
make the table less accessible.

- A listing of all forms and their fields, showing the label for each
field. Still trying to figure out whether form and field titles should be
part of this or not; see my other msg to the list this morning. This is
still a work in progress, and there are a few more checks I'll probably add
(positive tabindex values, labels pointing to non-existent or inapplicable
fields).

- A link to some brief-ish documentation we'll provide on the major issues
around accessibility, what template and content authors can do, how the
tools we provide can help, and what kinds of external tools and information
are available. This has yet to be written.

All these listings show full HTML of images and other formatted content if
there is any (in labels, links, etc), and clicking a listed item highlights
it visibly on the page, so you can see where to make changes. They also
flag missing or empty content.

The overall model isn't to evaluate whether the given link text etc is
appropriate, but rather to show you the relevant bits of navigation and
labeling, framed as what assistive technologies will see, to help you think
about how helpful they are. These are tools for content creators, not
accessibility experts, so they're ways to see how the page presents itself
to disabled visitors, not technically-oriented checks for and links to
specific sections of the standards,

There's some chance we'll also provide an easy way to submit individual
pages or possibly sections of a site to some external evaluation tool(s). I
have questions about this I'll post later on. We probably won't provide any
color checking tools, at least in this version.

Outside of these evaluation tools, the ability to assign ARIA landmark
roles to content containers has been ok'd too. There are some internal
technical hurdles that make this harder than it should be, so we'll have to
see how it plays out, but I'm quite hopeful on that score too.

If anyone has any further thoughts on what sorts of accessibility tools it
makes sense to provide in the context of a CMS for people who aren't
accessibility experts, please let me know, and thanks again for everyone's
help. Progress I think!

Dave Merrill


On Mon, Apr 22, 2013 at 10:17 AM, Dave Merrill < = EMAIL ADDRESS REMOVED = >wrote:

> Keeping in mind that we're a CMS vendor, providing tools for site and site
> template creators, not template or content creators ourselves, or site
> accessibility strategists, how about the following simpleminded proposal:
> 1. We provide HTML semantic containers and headings, which we want to do
> for other reasons
> 2. We provide an easy way to view the outline for the page you're working
> on
> 3. We provide the ability to assign ARIA landmark roles to content
> containers
>
> None of this guarantees that customers will ever look at the outline, or
> educate themselves about the use of the outline by assistive devices, about
> inconsistencies in current readers with outlines involving both semantic
> containers and headings, or about ARIA landmarks, or care about any of this.
>
> It does mean that simple tools are there for customers who want to use
> them, and they're more or less out of the way for people who aren't paying
> any attention to accessibility.
>
> I assume people are going to use headings sometimes because they always
> have, they make sense to them, and they have easy to understand styling
> implications. Given that, they're either going to create the outline they
> expect when they do that, or not, and feedback is the only way for them to
> learn how what they did actually worked out.
>
> Does this seem like a reasonable strategy? Is there any reason NOT to
> provide either #2 or #3? (#1 is definitely happening.)
>
> Thanks,
> Dave Merrill
>
>
> On Fri, Apr 19, 2013 at 8:37 AM, Dave Merrill < = EMAIL ADDRESS REMOVED = >wrote:
>
>> 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>>> > > To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>>> > > >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
>>> > > >> > To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS REMOVED = >
>>> > > >> >> To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
>>> > > >> >>>> >
>>> > > >> >>>> >