WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Responsive Web Design and Accessibility?

for

From: Bryan Garaventa
Date: Oct 5, 2012 4:17AM

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



--
www.iheni.com
@iheni