WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Responsive Web Design and Accessibility?

for

From: Bryan Garaventa
Date: Oct 5, 2012 1:19AM

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 REMOVED> >
To: < <EMAIL REMOVED> >; "WebAIM Discussion List"
< <EMAIL 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 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 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 REMOVED> >
> > To: "WebAIM Discussion List" < <EMAIL 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 REMOVED> <mailto: <EMAIL REMOVED> >
> > –––––––––––––––––––––––––––––––––––––––
> >
> > > > > > > >
> > > > > > > >
> >
> >
> > > >



--
www.iheni.com
@iheni