WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Responsive Web Design and Accessibility?

for

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

From: Rick Hill
Date: Thu, Oct 04 2012 6:18PM
Subject: Responsive Web Design and Accessibility?
No previous message | Next message →

I'll try again:

We are about to embark on upgrading our site(s) to a responsive design. I was wondering what resources (if any) exist that discuss the accessibility of responsive deigns, pro and con. Also, any techniques that can be used to make a responsive Web site more accessible?
–––––––––––––––––––––––––––––––––––––––
Rick Hill, Web CMS Administrator
University Communications, UC Davis
(530) 752-9612
http://cms.ucdavis.edu
–––––––––––––––––––––––––––––––––––––––
Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
–––––––––––––––––––––––––––––––––––––––

From: Bryan Garaventa
Date: Thu, Oct 04 2012 8:06PM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

You are welcome to use AccDC at
http://whatsock.com/
if you wish.

Which includes scalable functionality templates for lightboxes, banners,
tooltips, popups, tabs, menus, tree controls, keyboard and screen reader
accessible drag and drop, auto suggestion fields, sortable listboxes,
footnote generation, live chat, sliders, calendar pickers, accordions,
carousels, slideshows, and wizards.

All of which have been fully tested to ensure screen reader and keyboard
accessibility using accurate markup specifications.

Plus AccDC can be used to build anything else that you can imagine, and it's
free.

----- Original Message -----
From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 04, 2012 5:18 PM
Subject: Re: [WebAIM] Responsive Web Design and Accessibility?


I'll try again:

We are about to embark on upgrading our site(s) to a responsive design. I
was wondering what resources (if any) exist that discuss the accessibility
of responsive deigns, pro and con. Also, any techniques that can be used to
make a responsive Web site more accessible?
–––––––––––––––––––––––––––––––––––––––
Rick Hill, Web CMS Administrator
University Communications, UC Davis
(530) 752-9612
http://cms.ucdavis.edu
–––––––––––––––––––––––––––––––––––––––
Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
–––––––––––––––––––––––––––––––––––––––

From: Ken Petri
Date: Thu, Oct 04 2012 8:39PM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

Hi Rick,

The Web Experience Toolkit has a framework/template for responsive design
that has accessibility as a specific goal:
http://wet-boew.github.com/wet-boew/demos/index-eng.html

One place that is potentially problematic with a responsive design is the
menu system. If the menus are items in a single-level unordered list and
all the responsive design is doing is stacking them at a smaller screen
resolution, there probably will be no issues. As the menus get deeper and
more complex, though, you have to come up with different strategies for how
to handle deep menus on a small screen. There are lots of possibilities.
Here is a good overview:
http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/

It's probably pretty clear with which of these you could run into
accessibility issues. Keeping it simple is probably the best bet -- for
example, if there are dropdowns at full width, then consider setting
sub-menus to display:none and just creating a stack of top-level items when
the resolutions get mobile width. But there are other approaches that can
be pretty accessible (try the WET's mega menus at a narrow resolution for
example...).

In general, though, accessibility isn't going to suffer with a responsive
design. It's the same elements, just differently laid out/stacked. And so
long as you're keeping the visual hierarchy clear (no squeezing out of
white space or goofy-large headings), then accessibility should be just as
good as what was achieved at "desktop" widge/scale.

ken
--
Ken Petri
Program Director, OSU Web Accessibility Center




On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> You are welcome to use AccDC at
> http://whatsock.com/
> if you wish.
>
> Which includes scalable functionality templates for lightboxes, banners,
> tooltips, popups, tabs, menus, tree controls, keyboard and screen reader
> accessible drag and drop, auto suggestion fields, sortable listboxes,
> footnote generation, live chat, sliders, calendar pickers, accordions,
> carousels, slideshows, and wizards.
>
> All of which have been fully tested to ensure screen reader and keyboard
> accessibility using accurate markup specifications.
>
> Plus AccDC can be used to build anything else that you can imagine, and
> it's
> free.
>
> ----- Original Message -----
> From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, October 04, 2012 5:18 PM
> Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
>
>
> I'll try again:
>
> We are about to embark on upgrading our site(s) to a responsive design. I
> was wondering what resources (if any) exist that discuss the accessibility
> of responsive deigns, pro and con. Also, any techniques that can be used to
> make a responsive Web site more accessible?
> –––––––––––––––––––––––––––––––––––––––
> Rick Hill, Web CMS Administrator
> University Communications, UC Davis
> (530) 752-9612
> http://cms.ucdavis.edu
> –––––––––––––––––––––––––––––––––––––––
> Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> –––––––––––––––––––––––––––––––––––––––
>
> > > >
> > > >
>
>

From: Bryan Garaventa
Date: Thu, Oct 04 2012 11:55PM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

It's important to note that visual layout, styling, and resolution
considerations have little to no impact on screen reader and keyboard
accessibility.

----- Original Message -----
From: "Ken Petri" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 04, 2012 7:39 PM
Subject: Re: [WebAIM] Responsive Web Design and Accessibility?


Hi Rick,

The Web Experience Toolkit has a framework/template for responsive design
that has accessibility as a specific goal:
http://wet-boew.github.com/wet-boew/demos/index-eng.html

One place that is potentially problematic with a responsive design is the
menu system. If the menus are items in a single-level unordered list and
all the responsive design is doing is stacking them at a smaller screen
resolution, there probably will be no issues. As the menus get deeper and
more complex, though, you have to come up with different strategies for how
to handle deep menus on a small screen. There are lots of possibilities.
Here is a good overview:
http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/

It's probably pretty clear with which of these you could run into
accessibility issues. Keeping it simple is probably the best bet -- for
example, if there are dropdowns at full width, then consider setting
sub-menus to display:none and just creating a stack of top-level items when
the resolutions get mobile width. But there are other approaches that can
be pretty accessible (try the WET's mega menus at a narrow resolution for
example...).

In general, though, accessibility isn't going to suffer with a responsive
design. It's the same elements, just differently laid out/stacked. And so
long as you're keeping the visual hierarchy clear (no squeezing out of
white space or goofy-large headings), then accessibility should be just as
good as what was achieved at "desktop" widge/scale.

ken
--
Ken Petri
Program Director, OSU Web Accessibility Center




On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> You are welcome to use AccDC at
> http://whatsock.com/
> if you wish.
>
> Which includes scalable functionality templates for lightboxes, banners,
> tooltips, popups, tabs, menus, tree controls, keyboard and screen reader
> accessible drag and drop, auto suggestion fields, sortable listboxes,
> footnote generation, live chat, sliders, calendar pickers, accordions,
> carousels, slideshows, and wizards.
>
> All of which have been fully tested to ensure screen reader and keyboard
> accessibility using accurate markup specifications.
>
> Plus AccDC can be used to build anything else that you can imagine, and
> it's
> free.
>
> ----- Original Message -----
> From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, October 04, 2012 5:18 PM
> Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
>
>
> I'll try again:
>
> We are about to embark on upgrading our site(s) to a responsive design. I
> was wondering what resources (if any) exist that discuss the accessibility
> of responsive deigns, pro and con. Also, any techniques that can be used
> to
> make a responsive Web site more accessible?
> –––––––––––––––––––––––––––––––––––––––
> Rick Hill, Web CMS Administrator
> University Communications, UC Davis
> (530) 752-9612
> http://cms.ucdavis.edu
> –––––––––––––––––––––––––––––––––––––––
> Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> –––––––––––––––––––––––––––––––––––––––
>
> > > >
> > > >
>
>

From: Henny Swan
Date: Fri, Oct 05 2012 12:20AM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

Hi,

I agree with Ken that responsive web design is very much a friend of
accessibility however there are nuances that need to be taken into account
if content is to be usable for diverse users across devices.

All devices are not equal and the same goes for the capabilities of mobile
screen readers versus desktop screen readers as well as mobile versus
desktop browsers. In testing I have found different levels of support for
WAI ARIA on Android and iOS which is to be expected but what I wasn't
expecting was such poor support for basic HTML 4. For example title text is
not supported which in itself is not so terrible as title text is rarely
the right solution and is so abused on the web but it does mean that abbr,
is out of the question. Span is generally only supported on links rather
than plain text so you may want to think about how you present abbreviated
text for data table headers and so on.

When wireframing the site you may also want to think mobile first to ensure
that the structure you have on mobile makes sense on desktop and vice
versa. For example a news website may list news items with a heading, image
and abstract with the heading coded as an H2. On mobile the abstract may be
lost leaving a list of H2s with an image. I'd argue that the structure
makes less sense on mobile so you may want to code the news stories as list
items from the get go. In a similar way WAI ARIA landmarks may become noise
when content collapses onto mobile or skip links may become redundant. Note
the 'may' for all of these as all this needs to be considered in context on
a project by project bases.

Mobile Safari/Voiceover announces landmarks but wont identify them (i.e. it
it just says 'Landmark' rather than 'Landmark - Main') however it reads the
landmark out with the content that immediately follows it. As such you need
to think about content order: try and have the H1 immediately after where
the main landmark starts for example. Aria-label can also be used to
identify a landmark as this is supported on iOS and Android as well as some
desktop browsers.

There are other bits and pieces to take into consideration, a few of which
I have blogged about in recent posts covering mobile:
http://www.iheni.com/category/mobile/. In there you'll also find a link to
a podcast for Breaking Development where I talk about RWD (amongst other
things) with Tim Kadlec who also touched upon accessibility and RWD in his
new book 'Implementing Responsive Web Design'
http://timkadlec.com/2012/08/implementing-responsive-design-is-now-out/.

The big thing to keep in mind is to take nothing for granted with how a
mobile screen reader may output content and test the life out of your
content.

Henny

On 5 October 2012 03:39, Ken Petri < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Rick,
>
> The Web Experience Toolkit has a framework/template for responsive design
> that has accessibility as a specific goal:
> http://wet-boew.github.com/wet-boew/demos/index-eng.html
>
> One place that is potentially problematic with a responsive design is the
> menu system. If the menus are items in a single-level unordered list and
> all the responsive design is doing is stacking them at a smaller screen
> resolution, there probably will be no issues. As the menus get deeper and
> more complex, though, you have to come up with different strategies for how
> to handle deep menus on a small screen. There are lots of possibilities.
> Here is a good overview:
>
> http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/
>
> It's probably pretty clear with which of these you could run into
> accessibility issues. Keeping it simple is probably the best bet -- for
> example, if there are dropdowns at full width, then consider setting
> sub-menus to display:none and just creating a stack of top-level items when
> the resolutions get mobile width. But there are other approaches that can
> be pretty accessible (try the WET's mega menus at a narrow resolution for
> example...).
>
> In general, though, accessibility isn't going to suffer with a responsive
> design. It's the same elements, just differently laid out/stacked. And so
> long as you're keeping the visual hierarchy clear (no squeezing out of
> white space or goofy-large headings), then accessibility should be just as
> good as what was achieved at "desktop" widge/scale.
>
> ken
> --
> Ken Petri
> Program Director, OSU Web Accessibility Center
>
>
>
>
> On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > You are welcome to use AccDC at
> > http://whatsock.com/
> > if you wish.
> >
> > Which includes scalable functionality templates for lightboxes, banners,
> > tooltips, popups, tabs, menus, tree controls, keyboard and screen reader
> > accessible drag and drop, auto suggestion fields, sortable listboxes,
> > footnote generation, live chat, sliders, calendar pickers, accordions,
> > carousels, slideshows, and wizards.
> >
> > All of which have been fully tested to ensure screen reader and keyboard
> > accessibility using accurate markup specifications.
> >
> > Plus AccDC can be used to build anything else that you can imagine, and
> > it's
> > free.
> >
> > ----- Original Message -----
> > From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > Sent: Thursday, October 04, 2012 5:18 PM
> > Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
> >
> >
> > I'll try again:
> >
> > We are about to embark on upgrading our site(s) to a responsive design. I
> > was wondering what resources (if any) exist that discuss the
> accessibility
> > of responsive deigns, pro and con. Also, any techniques that can be used
> to
> > make a responsive Web site more accessible?
> > –––––––––––––––––––––––––––––––––––––––
> > Rick Hill, Web CMS Administrator
> > University Communications, UC Davis
> > (530) 752-9612
> > http://cms.ucdavis.edu
> > –––––––––––––––––––––––––––––––––––––––
> > Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > –––––––––––––––––––––––––––––––––––––––
> >
> > > > > > > >
> > > > > > > >
> >
> >
> > > >



--
www.iheni.com
@iheni

From: Bryan Garaventa
Date: Fri, Oct 05 2012 1:19AM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

I've noticed the same with basic ARIA support, in that many basic attributes
such as role=combobox, aria-selected, aria-label, and quite a few others
don't actually work properly in iOS Safari.

So I agree, testing is very important to identify where these pitfalls
occur.

Also, when identified as browser shortcomings, it's important to report them
to the manufacturer as bugs. Otherwise these problems will never go away.

I plan to submit the Safari ARIA bugs tomorrow, as soon as I can get an
Apple Dev account setup, which ironically isn't working because there
registration form is broken in IE, FF and Chrome. Hopefully I'll hear back
tomorrow though.

----- Original Message -----
From: "Henny Swan" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, October 04, 2012 11:20 PM
Subject: Re: [WebAIM] Responsive Web Design and Accessibility?


Hi,

I agree with Ken that responsive web design is very much a friend of
accessibility however there are nuances that need to be taken into account
if content is to be usable for diverse users across devices.

All devices are not equal and the same goes for the capabilities of mobile
screen readers versus desktop screen readers as well as mobile versus
desktop browsers. In testing I have found different levels of support for
WAI ARIA on Android and iOS which is to be expected but what I wasn't
expecting was such poor support for basic HTML 4. For example title text is
not supported which in itself is not so terrible as title text is rarely
the right solution and is so abused on the web but it does mean that abbr,
is out of the question. Span is generally only supported on links rather
than plain text so you may want to think about how you present abbreviated
text for data table headers and so on.

When wireframing the site you may also want to think mobile first to ensure
that the structure you have on mobile makes sense on desktop and vice
versa. For example a news website may list news items with a heading, image
and abstract with the heading coded as an H2. On mobile the abstract may be
lost leaving a list of H2s with an image. I'd argue that the structure
makes less sense on mobile so you may want to code the news stories as list
items from the get go. In a similar way WAI ARIA landmarks may become noise
when content collapses onto mobile or skip links may become redundant. Note
the 'may' for all of these as all this needs to be considered in context on
a project by project bases.

Mobile Safari/Voiceover announces landmarks but wont identify them (i.e. it
it just says 'Landmark' rather than 'Landmark - Main') however it reads the
landmark out with the content that immediately follows it. As such you need
to think about content order: try and have the H1 immediately after where
the main landmark starts for example. Aria-label can also be used to
identify a landmark as this is supported on iOS and Android as well as some
desktop browsers.

There are other bits and pieces to take into consideration, a few of which
I have blogged about in recent posts covering mobile:
http://www.iheni.com/category/mobile/. In there you'll also find a link to
a podcast for Breaking Development where I talk about RWD (amongst other
things) with Tim Kadlec who also touched upon accessibility and RWD in his
new book 'Implementing Responsive Web Design'
http://timkadlec.com/2012/08/implementing-responsive-design-is-now-out/.

The big thing to keep in mind is to take nothing for granted with how a
mobile screen reader may output content and test the life out of your
content.

Henny

On 5 October 2012 03:39, Ken Petri < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Rick,
>
> The Web Experience Toolkit has a framework/template for responsive design
> that has accessibility as a specific goal:
> http://wet-boew.github.com/wet-boew/demos/index-eng.html
>
> One place that is potentially problematic with a responsive design is the
> menu system. If the menus are items in a single-level unordered list and
> all the responsive design is doing is stacking them at a smaller screen
> resolution, there probably will be no issues. As the menus get deeper and
> more complex, though, you have to come up with different strategies for
> how
> to handle deep menus on a small screen. There are lots of possibilities.
> Here is a good overview:
>
> http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/
>
> It's probably pretty clear with which of these you could run into
> accessibility issues. Keeping it simple is probably the best bet -- for
> example, if there are dropdowns at full width, then consider setting
> sub-menus to display:none and just creating a stack of top-level items
> when
> the resolutions get mobile width. But there are other approaches that can
> be pretty accessible (try the WET's mega menus at a narrow resolution for
> example...).
>
> In general, though, accessibility isn't going to suffer with a responsive
> design. It's the same elements, just differently laid out/stacked. And so
> long as you're keeping the visual hierarchy clear (no squeezing out of
> white space or goofy-large headings), then accessibility should be just as
> good as what was achieved at "desktop" widge/scale.
>
> ken
> --
> Ken Petri
> Program Director, OSU Web Accessibility Center
>
>
>
>
> On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > You are welcome to use AccDC at
> > http://whatsock.com/
> > if you wish.
> >
> > Which includes scalable functionality templates for lightboxes, banners,
> > tooltips, popups, tabs, menus, tree controls, keyboard and screen reader
> > accessible drag and drop, auto suggestion fields, sortable listboxes,
> > footnote generation, live chat, sliders, calendar pickers, accordions,
> > carousels, slideshows, and wizards.
> >
> > All of which have been fully tested to ensure screen reader and keyboard
> > accessibility using accurate markup specifications.
> >
> > Plus AccDC can be used to build anything else that you can imagine, and
> > it's
> > free.
> >
> > ----- Original Message -----
> > From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > Sent: Thursday, October 04, 2012 5:18 PM
> > Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
> >
> >
> > I'll try again:
> >
> > We are about to embark on upgrading our site(s) to a responsive design.
> > I
> > was wondering what resources (if any) exist that discuss the
> accessibility
> > of responsive deigns, pro and con. Also, any techniques that can be used
> to
> > make a responsive Web site more accessible?
> > –––––––––––––––––––––––––––––––––––––––
> > Rick Hill, Web CMS Administrator
> > University Communications, UC Davis
> > (530) 752-9612
> > http://cms.ucdavis.edu
> > –––––––––––––––––––––––––––––––––––––––
> > Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > –––––––––––––––––––––––––––––––––––––––
> >
> > > > > > > >
> > > > > > > >
> >
> >
> > > >



--
www.iheni.com
@iheni

From: Henny Swan
Date: Fri, Oct 05 2012 1:36AM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | Next message →

I did some testing a while ago for WAI ARIA support on iOS, it doesn't
cover iOS 6 however.: http://www.iheni.com/wai-aria-support-on-ios/

I've raised a handful of bugs with Apple and have found them to be pretty
responsive.

Henny



On 5 October 2012 08:19, Bryan Garaventa < = EMAIL ADDRESS REMOVED = >wrote:

> I've noticed the same with basic ARIA support, in that many basic
> attributes
> such as role=combobox, aria-selected, aria-label, and quite a few others
> don't actually work properly in iOS Safari.
>
> So I agree, testing is very important to identify where these pitfalls
> occur.
>
> Also, when identified as browser shortcomings, it's important to report
> them
> to the manufacturer as bugs. Otherwise these problems will never go away.
>
> I plan to submit the Safari ARIA bugs tomorrow, as soon as I can get an
> Apple Dev account setup, which ironically isn't working because there
> registration form is broken in IE, FF and Chrome. Hopefully I'll hear back
> tomorrow though.
>
> ----- Original Message -----
> From: "Henny Swan" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
> < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, October 04, 2012 11:20 PM
> Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
>
>
> Hi,
>
> I agree with Ken that responsive web design is very much a friend of
> accessibility however there are nuances that need to be taken into account
> if content is to be usable for diverse users across devices.
>
> All devices are not equal and the same goes for the capabilities of mobile
> screen readers versus desktop screen readers as well as mobile versus
> desktop browsers. In testing I have found different levels of support for
> WAI ARIA on Android and iOS which is to be expected but what I wasn't
> expecting was such poor support for basic HTML 4. For example title text is
> not supported which in itself is not so terrible as title text is rarely
> the right solution and is so abused on the web but it does mean that abbr,
> is out of the question. Span is generally only supported on links rather
> than plain text so you may want to think about how you present abbreviated
> text for data table headers and so on.
>
> When wireframing the site you may also want to think mobile first to ensure
> that the structure you have on mobile makes sense on desktop and vice
> versa. For example a news website may list news items with a heading, image
> and abstract with the heading coded as an H2. On mobile the abstract may be
> lost leaving a list of H2s with an image. I'd argue that the structure
> makes less sense on mobile so you may want to code the news stories as list
> items from the get go. In a similar way WAI ARIA landmarks may become noise
> when content collapses onto mobile or skip links may become redundant. Note
> the 'may' for all of these as all this needs to be considered in context on
> a project by project bases.
>
> Mobile Safari/Voiceover announces landmarks but wont identify them (i.e. it
> it just says 'Landmark' rather than 'Landmark - Main') however it reads the
> landmark out with the content that immediately follows it. As such you need
> to think about content order: try and have the H1 immediately after where
> the main landmark starts for example. Aria-label can also be used to
> identify a landmark as this is supported on iOS and Android as well as some
> desktop browsers.
>
> There are other bits and pieces to take into consideration, a few of which
> I have blogged about in recent posts covering mobile:
> http://www.iheni.com/category/mobile/. In there you'll also find a link to
> a podcast for Breaking Development where I talk about RWD (amongst other
> things) with Tim Kadlec who also touched upon accessibility and RWD in his
> new book 'Implementing Responsive Web Design'
> http://timkadlec.com/2012/08/implementing-responsive-design-is-now-out/.
>
> The big thing to keep in mind is to take nothing for granted with how a
> mobile screen reader may output content and test the life out of your
> content.
>
> Henny
>
> On 5 October 2012 03:39, Ken Petri < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi Rick,
> >
> > The Web Experience Toolkit has a framework/template for responsive design
> > that has accessibility as a specific goal:
> > http://wet-boew.github.com/wet-boew/demos/index-eng.html
> >
> > One place that is potentially problematic with a responsive design is the
> > menu system. If the menus are items in a single-level unordered list and
> > all the responsive design is doing is stacking them at a smaller screen
> > resolution, there probably will be no issues. As the menus get deeper and
> > more complex, though, you have to come up with different strategies for
> > how
> > to handle deep menus on a small screen. There are lots of possibilities.
> > Here is a good overview:
> >
> >
> http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/
> >
> > It's probably pretty clear with which of these you could run into
> > accessibility issues. Keeping it simple is probably the best bet -- for
> > example, if there are dropdowns at full width, then consider setting
> > sub-menus to display:none and just creating a stack of top-level items
> > when
> > the resolutions get mobile width. But there are other approaches that can
> > be pretty accessible (try the WET's mega menus at a narrow resolution for
> > example...).
> >
> > In general, though, accessibility isn't going to suffer with a responsive
> > design. It's the same elements, just differently laid out/stacked. And so
> > long as you're keeping the visual hierarchy clear (no squeezing out of
> > white space or goofy-large headings), then accessibility should be just
> as
> > good as what was achieved at "desktop" widge/scale.
> >
> > ken
> > --
> > Ken Petri
> > Program Director, OSU Web Accessibility Center
> >
> >
> >
> >
> > On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > You are welcome to use AccDC at
> > > http://whatsock.com/
> > > if you wish.
> > >
> > > Which includes scalable functionality templates for lightboxes,
> banners,
> > > tooltips, popups, tabs, menus, tree controls, keyboard and screen
> reader
> > > accessible drag and drop, auto suggestion fields, sortable listboxes,
> > > footnote generation, live chat, sliders, calendar pickers, accordions,
> > > carousels, slideshows, and wizards.
> > >
> > > All of which have been fully tested to ensure screen reader and
> keyboard
> > > accessibility using accurate markup specifications.
> > >
> > > Plus AccDC can be used to build anything else that you can imagine, and
> > > it's
> > > free.
> > >
> > > ----- Original Message -----
> > > From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> > > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > > Sent: Thursday, October 04, 2012 5:18 PM
> > > Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
> > >
> > >
> > > I'll try again:
> > >
> > > We are about to embark on upgrading our site(s) to a responsive design.
> > > I
> > > was wondering what resources (if any) exist that discuss the
> > accessibility
> > > of responsive deigns, pro and con. Also, any techniques that can be
> used
> > to
> > > make a responsive Web site more accessible?
> > > –––––––––––––––––––––––––––––––––––––––
> > > Rick Hill, Web CMS Administrator
> > > University Communications, UC Davis
> > > (530) 752-9612
> > > http://cms.ucdavis.edu
> > > –––––––––––––––––––––––––––––––––––––––
> > > Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > > –––––––––––––––––––––––––––––––––––––––
> > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > >
> > >
> > > > > > > >
>
>
>
> --
> www.iheni.com
> @iheni
> > > >
> > > >



--
www.iheni.com
@iheni

From: Bryan Garaventa
Date: Fri, Oct 05 2012 4:17AM
Subject: Re: Responsive Web Design and Accessibility?
← Previous message | No next message

Thanks, this helps as a comparison.

The issues I've been seeing though have to do with specific attribute
combinations though, and not necessarily broad control types.

E.G

This toggle button reads correctly in iOS devices as "Options Toggle Button"

<a href="#" role="button" aria-pressed="false">
<span class="lbl"> Options </span>
</a>

However, this toggle button does not, only announced as "Toggle Button"

<a href="#" role="button" aria-pressed="false" aria-label="Options">
<img src="url.jpg" alt="Options" />
</a>

In many cases, the supporting ARIA attributes for complex control types are
ignored.

E.G

http://whatsock.com/modules/aria_tree_from_xml_module/demo.htm

If the values for aria-level, aria-posinset, aria-setsize, and aria-selected
were accurately conveyed in the above template using iOS Safari, this tree
would be fully accessible, since you can already tap on any tree node using
Voiceover successfully to expand/collapse branches. Voiceover simply needs
to convey the correct feedback using the values that are already present in
the tree structure to announce proper role and state information.

I've got a lot of examples like this.

The good news however, is that the coding for such templates as these is
sound, so as soon as Voiceover supports the reading of supporting ARIA
attributes for complex control types, iOS accessibility support will be
retroactive and require no coding changes.


----- Original Message -----
From: "Henny Swan" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, October 05, 2012 12:36 AM
Subject: Re: [WebAIM] Responsive Web Design and Accessibility?


I did some testing a while ago for WAI ARIA support on iOS, it doesn't
cover iOS 6 however.: http://www.iheni.com/wai-aria-support-on-ios/

I've raised a handful of bugs with Apple and have found them to be pretty
responsive.

Henny



On 5 October 2012 08:19, Bryan Garaventa
< = EMAIL ADDRESS REMOVED = >wrote:

> I've noticed the same with basic ARIA support, in that many basic
> attributes
> such as role=combobox, aria-selected, aria-label, and quite a few others
> don't actually work properly in iOS Safari.
>
> So I agree, testing is very important to identify where these pitfalls
> occur.
>
> Also, when identified as browser shortcomings, it's important to report
> them
> to the manufacturer as bugs. Otherwise these problems will never go away.
>
> I plan to submit the Safari ARIA bugs tomorrow, as soon as I can get an
> Apple Dev account setup, which ironically isn't working because there
> registration form is broken in IE, FF and Chrome. Hopefully I'll hear back
> tomorrow though.
>
> ----- Original Message -----
> From: "Henny Swan" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
> < = EMAIL ADDRESS REMOVED = >
> Sent: Thursday, October 04, 2012 11:20 PM
> Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
>
>
> Hi,
>
> I agree with Ken that responsive web design is very much a friend of
> accessibility however there are nuances that need to be taken into account
> if content is to be usable for diverse users across devices.
>
> All devices are not equal and the same goes for the capabilities of mobile
> screen readers versus desktop screen readers as well as mobile versus
> desktop browsers. In testing I have found different levels of support for
> WAI ARIA on Android and iOS which is to be expected but what I wasn't
> expecting was such poor support for basic HTML 4. For example title text
> is
> not supported which in itself is not so terrible as title text is rarely
> the right solution and is so abused on the web but it does mean that abbr,
> is out of the question. Span is generally only supported on links rather
> than plain text so you may want to think about how you present abbreviated
> text for data table headers and so on.
>
> When wireframing the site you may also want to think mobile first to
> ensure
> that the structure you have on mobile makes sense on desktop and vice
> versa. For example a news website may list news items with a heading,
> image
> and abstract with the heading coded as an H2. On mobile the abstract may
> be
> lost leaving a list of H2s with an image. I'd argue that the structure
> makes less sense on mobile so you may want to code the news stories as
> list
> items from the get go. In a similar way WAI ARIA landmarks may become
> noise
> when content collapses onto mobile or skip links may become redundant.
> Note
> the 'may' for all of these as all this needs to be considered in context
> on
> a project by project bases.
>
> Mobile Safari/Voiceover announces landmarks but wont identify them (i.e.
> it
> it just says 'Landmark' rather than 'Landmark - Main') however it reads
> the
> landmark out with the content that immediately follows it. As such you
> need
> to think about content order: try and have the H1 immediately after where
> the main landmark starts for example. Aria-label can also be used to
> identify a landmark as this is supported on iOS and Android as well as
> some
> desktop browsers.
>
> There are other bits and pieces to take into consideration, a few of which
> I have blogged about in recent posts covering mobile:
> http://www.iheni.com/category/mobile/. In there you'll also find a link to
> a podcast for Breaking Development where I talk about RWD (amongst other
> things) with Tim Kadlec who also touched upon accessibility and RWD in his
> new book 'Implementing Responsive Web Design'
> http://timkadlec.com/2012/08/implementing-responsive-design-is-now-out/.
>
> The big thing to keep in mind is to take nothing for granted with how a
> mobile screen reader may output content and test the life out of your
> content.
>
> Henny
>
> On 5 October 2012 03:39, Ken Petri < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi Rick,
> >
> > The Web Experience Toolkit has a framework/template for responsive
> > design
> > that has accessibility as a specific goal:
> > http://wet-boew.github.com/wet-boew/demos/index-eng.html
> >
> > One place that is potentially problematic with a responsive design is
> > the
> > menu system. If the menus are items in a single-level unordered list and
> > all the responsive design is doing is stacking them at a smaller screen
> > resolution, there probably will be no issues. As the menus get deeper
> > and
> > more complex, though, you have to come up with different strategies for
> > how
> > to handle deep menus on a small screen. There are lots of possibilities.
> > Here is a good overview:
> >
> >
> http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/
> >
> > It's probably pretty clear with which of these you could run into
> > accessibility issues. Keeping it simple is probably the best bet -- for
> > example, if there are dropdowns at full width, then consider setting
> > sub-menus to display:none and just creating a stack of top-level items
> > when
> > the resolutions get mobile width. But there are other approaches that
> > can
> > be pretty accessible (try the WET's mega menus at a narrow resolution
> > for
> > example...).
> >
> > In general, though, accessibility isn't going to suffer with a
> > responsive
> > design. It's the same elements, just differently laid out/stacked. And
> > so
> > long as you're keeping the visual hierarchy clear (no squeezing out of
> > white space or goofy-large headings), then accessibility should be just
> as
> > good as what was achieved at "desktop" widge/scale.
> >
> > ken
> > --
> > Ken Petri
> > Program Director, OSU Web Accessibility Center
> >
> >
> >
> >
> > On Thu, Oct 4, 2012 at 10:06 PM, Bryan Garaventa <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > You are welcome to use AccDC at
> > > http://whatsock.com/
> > > if you wish.
> > >
> > > Which includes scalable functionality templates for lightboxes,
> banners,
> > > tooltips, popups, tabs, menus, tree controls, keyboard and screen
> reader
> > > accessible drag and drop, auto suggestion fields, sortable listboxes,
> > > footnote generation, live chat, sliders, calendar pickers, accordions,
> > > carousels, slideshows, and wizards.
> > >
> > > All of which have been fully tested to ensure screen reader and
> keyboard
> > > accessibility using accurate markup specifications.
> > >
> > > Plus AccDC can be used to build anything else that you can imagine,
> > > and
> > > it's
> > > free.
> > >
> > > ----- Original Message -----
> > > From: "Rick Hill" < = EMAIL ADDRESS REMOVED = >
> > > To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> > > Sent: Thursday, October 04, 2012 5:18 PM
> > > Subject: Re: [WebAIM] Responsive Web Design and Accessibility?
> > >
> > >
> > > I'll try again:
> > >
> > > We are about to embark on upgrading our site(s) to a responsive
> > > design.
> > > I
> > > was wondering what resources (if any) exist that discuss the
> > accessibility
> > > of responsive deigns, pro and con. Also, any techniques that can be
> used
> > to
> > > make a responsive Web site more accessible?
> > > –––––––––––––––––––––––––––––––––––––––
> > > Rick Hill, Web CMS Administrator
> > > University Communications, UC Davis
> > > (530) 752-9612
> > > http://cms.ucdavis.edu
> > > –––––––––––––––––––––––––––––––––––––––
> > > Web CMS assistance at = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> > > –––––––––––––––––––––––––––––––––––––––
> > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > >
> > >
> > > > > > > >
>
>
>
> --
> www.iheni.com
> @iheni
> > > >
> > > >



--
www.iheni.com
@iheni