E-mail List Archives

Search E-mail List Archives for

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

From: Dave Merrill
Date: Wed, Apr 17 2013 9:55AM
Subject: Value and prioritization of large-scale things a web site can do for improved accessibility
No previous message | Next message →

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

From: Steve Green
Date: Wed, Apr 17 2013 10:51AM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Wed, Apr 17 2013 11:27AM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Detlev Fischer
Date: Wed, Apr 17 2013 11:49AM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Hi Dave,

One thing not on your list I would throw in because it makes a big difference to keyboard users AND will be relatively easy to implement via CSS: making sure that you have always have good visibility of current keyboard focus on interactive elements when tabbing through content. From my experience of testing sites, even on sites with decent overall focus visibility, I often find areas where the focus is difficult to see.

Best, Detlev

On 17 Apr 2013, at 19:27, Dave Merrill wrote:

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

From: Steve Green
Date: Wed, Apr 17 2013 11:59AM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Humbert, Joseph A
Date: Wed, Apr 17 2013 12:06PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Hi All,

I would say No to:

"Place all content within HTML5 semantic container tags, specifically article, aside ,nav, section, figure, figcaption, footer, header, and main"

Because the HTML5 outline algorithm (http://dev.w3.org/html5/spec/sections.html#outlines) is not supported by all adaptive technology and Web browser combinations. Therefore, if you use the sematic tags you will end up with an incorrect heading structure in some cases and not others. I just tested with JAWS 14, NVDA 2013, Voiceover on IE9, FF 20, Safari 5. NVDA and Voiceover both had issues. Thankx.

Reference:
http://www.accessibleculture.org/articles/2011/10/jaws-ie-and-headings-in-html5/
http://html5accessibility.com/

Joe Humbert, Accessibility Specialist
UITS Adaptive Technology and Accessibility Centers
Indiana University, Indianapolis and Bloomington
535 W Michigan St. IT214 E
Indianapolis, IN 46202
Office Phone: (317) 274-4378
Cell Phone: (317) 644-6824
= EMAIL ADDRESS REMOVED =
http://iuadapts.Indiana.edu/

From: Dave Merrill
Date: Wed, Apr 17 2013 12:08PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Thanks Detlev. I work on a commercial CMS, and in that context, we don't
have much if any input on the CSS or other styling our customers do for
sites built with our tools. That, along with text and image contrast,
choice of interactive content and media, has to be dealt with by our
customers' designers, when it's a priority.

What we *can* do is provide tools for creating discoverable and navigatable
page structures, and that's what I'm focusing on for now.


On Wed, Apr 17, 2013 at 1:49 PM, Detlev Fischer < = EMAIL ADDRESS REMOVED =
> wrote:

> Hi Dave,
>
> One thing not on your list I would throw in because it makes a big
> difference to keyboard users AND will be relatively easy to implement via
> CSS: making sure that you have always have good visibility of current
> keyboard focus on interactive elements when tabbing through content. From
> my experience of testing sites, even on sites with decent overall focus
> visibility, I often find areas where the focus is difficult to see.
>
> Best, Detlev
>
> On 17 Apr 2013, at 19:27, Dave Merrill wrote:
>
> > 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 ADDRESS 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
> >>
> >>

From: Dave Merrill
Date: Wed, Apr 17 2013 12:19PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Wed, Apr 17 2013 12:22PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

One thing to be aware of, ARIA such as aria-labelledby cannot be used to
link two static elements. Nothing will be announced to screen reader users
during navigation.

----- Original Message -----
From: "Dave Merrill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, April 17, 2013 10:27 AM
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 ADDRESS 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
>>
>>

From: Bryan Garaventa
Date: Wed, Apr 17 2013 12:25PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

I should qualify that by saying, two static elements that are not
interactive ARIA widgets or active elements.

----- Original Message -----
From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, April 17, 2013 11:22 AM
Subject: Re: [WebAIM] Value and prioritization of large-scale things a web
site can do for improved accessibility


> One thing to be aware of, ARIA such as aria-labelledby cannot be used to
> link two static elements. Nothing will be announced to screen reader users
> during navigation.
>
> ----- Original Message -----
> From: "Dave Merrill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, April 17, 2013 10:27 AM
> 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 ADDRESS 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
>>>
>>>

From: Dave Merrill
Date: Wed, Apr 17 2013 12:45PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Thanks Joe.

The coexistence of explicit heading levels and a nested container hierarchy
definitely is messy, no question. I hope that doesn't mean semantic
containers can't ever be used though.

Do you think the use of h1 at every level, like some examples in the
standard, is the cause of the reader problems you see? I personally don't
expect real sites to do that, standards or not, because the css required to
style nested headings appropriately is prohibitively verbose and
inefficient. If heading levels are appropriate for their location within
the semantic hierarchy, does that work reliably?

Ultimately, from my perch at a CMS vendor, these decisions are really
our customers' to make. So far, it seem right to me that we provide tools
for semantic containers, headings, ARIA landmarks, and possibly some
ARIA labeling and let each site planner decide what their strategy will
be. Tomorrow's usual may not be the same as today's.


On Wed, Apr 17, 2013 at 2:06 PM, Humbert, Joseph A < = EMAIL ADDRESS REMOVED = >wrote:

> Hi All,
>
> I would say No to:
>
> "Place all content within HTML5 semantic container tags, specifically
> article, aside ,nav, section, figure, figcaption, footer, header, and main"
>
> Because the HTML5 outline algorithm (
> http://dev.w3.org/html5/spec/sections.html#outlines) is not supported by
> all adaptive technology and Web browser combinations. Therefore, if you
> use the sematic tags you will end up with an incorrect heading structure in
> some cases and not others. I just tested with JAWS 14, NVDA 2013, Voiceover
> on IE9, FF 20, Safari 5. NVDA and Voiceover both had issues. Thankx.
>
> Reference:
>
> http://www.accessibleculture.org/articles/2011/10/jaws-ie-and-headings-in-html5/
> http://html5accessibility.com/
>
> Joe Humbert, Accessibility Specialist
> UITS Adaptive Technology and Accessibility Centers
> Indiana University, Indianapolis and Bloomington
> 535 W Michigan St. IT214 E
> Indianapolis, IN 46202
> Office Phone: (317) 274-4378
> Cell Phone: (317) 644-6824
> = EMAIL ADDRESS REMOVED =
> http://iuadapts.Indiana.edu/
>

From: Dave Merrill
Date: Wed, Apr 17 2013 12:54PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Ah, that is indeed an important thing I wasn't aware of. (That's why I'm
here, to learn from more experienced practitioners!) That seems to say that
they're completely inappropriate for static content. Right?

My understanding is that ARIA landmarks aren't announced on entry to a
page, but readers have commands to move to the next and previous ones. Is
that right? What attributes of a landmark get announced when you navigate
to it? They're way more generic than headings, so just stepping through
them might be useful, but only if you knew where you were, and what else
was available nearby.


On Wed, Apr 17, 2013 at 2:22 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> One thing to be aware of, ARIA such as aria-labelledby cannot be used to
> link two static elements. Nothing will be announced to screen reader users
> during navigation.
>
> ----- Original Message -----
> From: "Dave Merrill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, April 17, 2013 10:27 AM
> 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 ADDRESS 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
> >>
> >>

From: Steve Green
Date: Wed, Apr 17 2013 12:54PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Paul J. Adam
Date: Wed, Apr 17 2013 1:02PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Wed, Apr 17 2013 1:08PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

Would aria-labelledby be useful for static content whose best description
was NOT in the first heading inside it?

My overall goal to come up with a cohesive and useful set of tools for site
template designers to make their (largely static) content as widely
accessible as possible. In that sense, aria-labelledby might be worth
providing for the cases where it was useful, even if that wasn't most of
them.

But overall, as I think about it, I think the majority of our customer base
isn't that sophisticated about accessibility. They may well not have an
accessibility specialist even, just somebody with a flair for design and
some HTML experience, possibly also a coder, who's tasked with template
creation. For them, a simpler set of tools that was harder to make a mess
with is probably a better strategy.


On Wed, Apr 17, 2013 at 2: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
>
>

From: Dave Merrill
Date: Wed, Apr 17 2013 1:21PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Wed, Apr 17 2013 1:25PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

(Just to clarify, template creators do so in our UI, not HTML, though there
are various ways to go full custom if you have the knowledge and need to..
Supporting these attributes means we provide places in our UI to enter
them, then render the corresponding HTML for site visitors.)


On Wed, Apr 17, 2013 at 3:21 PM, Dave Merrill < = EMAIL ADDRESS REMOVED = >wrote:

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

From: Humbert, Joseph A
Date: Wed, Apr 17 2013 1:59PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

The biggest problem I have tested (and left out in my first email ) is that JAWS 14 in IE9 and Firefox 20 relates incorrect heading levels for correctly coded HTML Headings in HTML5 Elements.

Coded structure:
<h1>Explicitly Ranked Headings</h1>
<nav>
<h2>Navigation</h2>
</nav>
<section>
<h2>Section</h2>
<article>
<h3>Article</h3>
<section>
<h4>Subsection</h4>
</section>
</article>
</section>
<aside>
<h2>Aside</h2>
</aside>

JAWS Heading List (FF20):
h1. Explicitly Ranked Headings
h3. Navigation
h3. Section
h5. Article
h2. Subsection
h3. Aside

Only difference between IE 9 and Firefox 20 is IE 9 drops out the h2. Subsection entirely.

So my advice would be to include the capabilities in your system, but include verbose documentation as to the current pitfalls.

- Joe

From: Birkir R. Gunnarsson
Date: Wed, Apr 17 2013 1:59PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

A few thoughts:
It is important that webpage title be descriptive and that webpage
language be explictly set in its head section.
Is this something you could prompt your customers to do when creating
a new page from a template?
Page title should indicate subpage | site in my opinion, for instance
Inbox | GMail
(or vice versa).
Page title is the first thing most screen readers read automatically
when a page is loaded.
Page language is generally not a big problem for people in the U.S.
but in Europe there is a lot of French, German or Danish screen
readers, for instance, that may start reading a website with the wrong
speech synthesizer if it is not aware of its language.

For landmarks and html5 elements (which many screen readers are not
sure how to deal with yet, and do so by treating them like landmarks),
make sure they are not over used.
Screen readers offer users navigation keys to jump to next or previous
landmark (; and shift-; in Jaws, d and shift-d in NVDA for instance).
You can also list all the landmarks on a webpage, though I usually do not do it.

I am beginning to see a lot of site that throw in the section and
article elements very generously, making the landmarks a lot less
useful and creating a lot of noise.
Imagine a news article site with 20 headlines, when each of them s
wrapped inside an Article tag, evenif it is just a link with possible
2 lines of text, these are all treated and announced as article
regions by some screen readers. Sections are just announced as regions
by Jaws at least.

so if we had
<code>
<section>

<article>
<h2>my headline text</h2>
</article>
</section
</code>
...
Jaws would respond this way when pressing the ; key.

region
article
...

It also announces these for users who are navigating the page by
pressing the arrow down key in thir virtual buffer.


Assume you had this markup for every news headline with a line of text
on the site and you may end up with 30 to 50 aria landmarks on a
webpage, making them useless as a structural markup and adding 30 to
50 lines containing the single word "region" or "article" to users who
are slow or want to inspect the site with arrow keys only, making the
site very cumbersome and content hard to get to.

Each page should have one MAIN aria landmark.
Banner should be the landmark around the header content.
contentinfo should mark the footer content
A navigation landmark is useful for navigation menus on the site. I
personally often recommend to add an aria-label to a navigation
landmark when you have multiple navigation menus on a site.

Global navigation (your standard menu on all pages)

My actions (if user is logged in and can perform certain actions only
when logged in).

etc.

I still recommend using div over section, until screen readers better
know how to treat sections, at least be careful and use section
according to spec.

I have recommended that the article tag be used no more than once on a
site, i.e. the article element is useful when user loads a site with
one article (more than 5 lines of contiguous text).

Imagine if you put an h1 heading for the article inside an article tag
inside a main tag (because it is the main content of the page).

<code>
<main role="main">
<article>
<h1>My headline</h1>
</artile>
</main>
</code>
Again Jaws will announce
main
article
heading level 1 my headline text
If you use an arrow key to explore the site you will hear "main"
"article" "headinglevel 1 text".

Here, if the article is marked up as the only h1 heading on the site,
the landmarks add nothing of value but unnecessary noise, especially
when you throw the main and the article landmark together.

It would be useful to add required or aria=required="true" to form fields.
Again, I am just giving examples of the problems. It is hard to come
up with one-size-fits-all rules for these things.

Hope you find some of these thoughts useful.
-B

On 4/17/13, Dave Merrill < = EMAIL ADDRESS REMOVED = > wrote:
> 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
>> >
>> >

From: Birkir R. Gunnarsson
Date: Wed, Apr 17 2013 2:00PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

P.S. titles are really only useful when they are the webpage title or
the title of frames/iFrames (titles for frames/iframes are required
and announced by all A.T. as far as I know).
.. other titles, such as on links, buttons etc. are read
inconsistently, often not at all, by screen readers.


On 4/17/13, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> A few thoughts:
> It is important that webpage title be descriptive and that webpage
> language be explictly set in its head section.
> Is this something you could prompt your customers to do when creating
> a new page from a template?
> Page title should indicate subpage | site in my opinion, for instance
> Inbox | GMail
> (or vice versa).
> Page title is the first thing most screen readers read automatically
> when a page is loaded.
> Page language is generally not a big problem for people in the U.S.
> but in Europe there is a lot of French, German or Danish screen
> readers, for instance, that may start reading a website with the wrong
> speech synthesizer if it is not aware of its language.
>
> For landmarks and html5 elements (which many screen readers are not
> sure how to deal with yet, and do so by treating them like landmarks),
> make sure they are not over used.
> Screen readers offer users navigation keys to jump to next or previous
> landmark (; and shift-; in Jaws, d and shift-d in NVDA for instance).
> You can also list all the landmarks on a webpage, though I usually do not do
> it.
>
> I am beginning to see a lot of site that throw in the section and
> article elements very generously, making the landmarks a lot less
> useful and creating a lot of noise.
> Imagine a news article site with 20 headlines, when each of them s
> wrapped inside an Article tag, evenif it is just a link with possible
> 2 lines of text, these are all treated and announced as article
> regions by some screen readers. Sections are just announced as regions
> by Jaws at least.
>
> so if we had
> <code>
> <section>
>
> <article>
> <h2>my headline text</h2>
> </article>
> </section
> </code>
> ...
> Jaws would respond this way when pressing the ; key.
>
> region
> article
> ...
>
> It also announces these for users who are navigating the page by
> pressing the arrow down key in thir virtual buffer.
>
>
> Assume you had this markup for every news headline with a line of text
> on the site and you may end up with 30 to 50 aria landmarks on a
> webpage, making them useless as a structural markup and adding 30 to
> 50 lines containing the single word "region" or "article" to users who
> are slow or want to inspect the site with arrow keys only, making the
> site very cumbersome and content hard to get to.
>
> Each page should have one MAIN aria landmark.
> Banner should be the landmark around the header content.
> contentinfo should mark the footer content
> A navigation landmark is useful for navigation menus on the site. I
> personally often recommend to add an aria-label to a navigation
> landmark when you have multiple navigation menus on a site.
>
> Global navigation (your standard menu on all pages)
>
> My actions (if user is logged in and can perform certain actions only
> when logged in).
>
> etc.
>
> I still recommend using div over section, until screen readers better
> know how to treat sections, at least be careful and use section
> according to spec.
>
> I have recommended that the article tag be used no more than once on a
> site, i.e. the article element is useful when user loads a site with
> one article (more than 5 lines of contiguous text).
>
> Imagine if you put an h1 heading for the article inside an article tag
> inside a main tag (because it is the main content of the page).
>
> <code>
> <main role="main">
> <article>
> <h1>My headline</h1>
> </artile>
> </main>
> </code>
> Again Jaws will announce
> main
> article
> heading level 1 my headline text
> If you use an arrow key to explore the site you will hear "main"
> "article" "headinglevel 1 text".
>
> Here, if the article is marked up as the only h1 heading on the site,
> the landmarks add nothing of value but unnecessary noise, especially
> when you throw the main and the article landmark together.
>
> It would be useful to add required or aria=required="true" to form fields.
> Again, I am just giving examples of the problems. It is hard to come
> up with one-size-fits-all rules for these things.
>
> Hope you find some of these thoughts useful.
> -B
>
> On 4/17/13, Dave Merrill < = EMAIL ADDRESS REMOVED = > wrote:
>> 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
>>> >
>>> >

From: Bryan Garaventa
Date: Wed, Apr 17 2013 2:08PM
Subject: Re: Value and prioritization of large-scale things a web site can do for improved accessibility
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Wed, Apr 17 2013 5:10PM
Subject: Re: Value and prioritization of large-scale things a website can do for improved accessibility
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Wed, Apr 17 2013 11:54PM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Elle
Date: Thu, Apr 18 2013 6:52AM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Thu, Apr 18 2013 8:12AM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Thu, Apr 18 2013 5:42PM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Thu, Apr 18 2013 9:30PM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Elle
Date: Fri, Apr 19 2013 5:51AM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Fri, Apr 19 2013 6:37AM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | Next message →

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

From: Dave Merrill
Date: Mon, Apr 22 2013 8:17AM
Subject: Re: Value and prioritization of large-scale things awebsite can do for improved accessibility
← Previous message | No next message

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