WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Yet another tab panel implementation

for

From: Robert Fentress
Date: Sep 21, 2015 12:33PM

Hi, Dejan.

Several things occur to me, looking at this implementation:

- For the dialog, why use role="alert" and aria-live="assertive", rather
than role="dialog", if this is to serve as a dialog?
- By placing the tab panel widget in a div marked assertive, without
other attributes, any change to the contents causes everything
within it to
be read anytime anything changes, which I suspect screen reader
users would
find intrusive.
- Loading the page in IE with JAWS causes the word alert to be voiced
7 times. I'm just guessing without exploring further, but
perhaps this is
announcing each focusable element in the dialog div because you
have marked
it role="alert"?
- It appears as if you have set the entire tab panel as a tab stop,
which I find problematic, since it causes everything in the tab panel to be
read when it receives focus, which I suspect would be considered intrusive
by screen reader users.
- While the use of radio buttons for tabs is tempting, since the
keyboard interaction pattern behavior of tabs and radio buttons is similar,
they are not semantically the same. I suspect this might be confusing for a
screen reader user who, when he tabs to a radio button finds a mishmash of
radio button and tab behavior.
- In particular, placing the labels for the radio buttons in an
unordered list after the radio buttons strikes me as unusual and perhaps
against the HTML specification (I'd need to check). In either case, I
suspect it would be confusing for JAWS/IE users, since, in that screen
reader/browser combination, in Virtual PC Cursor mode, the labels and
buttons are read separately. This means that the radio button would be
voiced one after another using the arrow keys, but, then, once
they had all
been read, the labels would be read again separately as tabs.
- I only speak English, so it was hard for me to follow everything that
was going on, but, when an item in the radio button group has focus and I
use the arrow keys to move between tabs, I am only informed that I am on a
particular tab after the entirety of the tab panel contents are read.

I suspect there are some other issues, but that is a start. Sorry if I'm
overlook some subtleties in why you have made the design decisions you did
here, but I thought I'd make a contribution quickly, rather than look at it
long and hard and risk of writing nothing because I got distracted by other
things.

I wish I could provide you some guidance on what the best way to code a tab
panel widget is, but I've been researching this for quite a while for
something else I've been doing and, in my experience, every implementation
I've looked at deals with things in a different way. I don't know, at this
point, what user expectations are regarding this pattern. I'd love to hear
what others think.

Hope that helps!

Best,
Rob

On Sun, Sep 13, 2015 at 11:08 PM, Dejan Kozina < <EMAIL REMOVED> > wrote:

> Hello list,
>
> I'd like to hear your critics and advice regarding a CSS-only tab panel
> widget I implemented recently.
>
> ISSUE: the EU cookie normative (as interpreted in Italy) requires for a
> website to intrusively ask for consent before placing any tracking
> cookie, be it its own or by a third party (think embedded Google Maps or
> Youtube videos). Also, the website itself is multilingual – so I guess
> the consent form itself should be multilingual, even if this is not
> explicitly required by law. The lawmakers suggest a pop-up, which sounds
> odd and somewhat dirty to me - this would deny any visitor with
> scripting disabled the right to make a choice. One more requirement was
> that the whole thing had to be easy to implement on various existing old
> websites without having to rewrite them too much;
>
> IMPLEMENTATION: an absolutely positioned form with role=dialog and
> aria-live=assertive containing a CSS-only tab panel widget where tab
> represent the language choice; selecting a tab causes the form controls
> and relative text in the selected language to be presented onscreen. At
> screen widths below 420px the whole thing morphs into a CSS-only
> accordion; there is some scripting too added at the end: this is not
> required for the widget to work, but helps in switching the aria-* and
> tabindex attributes to the correct values upon language choice; the
> whole thing is included at the end of the document to prevent search
> engines to describe every page with 'this website may contain
> third-party content...';
>
> DEMO: an example is deployed at http://almiticoeremita.com, where a
> consent form appears on every page until the visitor either clicks OK or
> NO or goes further to allow or deny cookies one by one on a separated
> page; if you click on one of the buttons you have to delete the cookie
> named 'cookieconsent' to have the form reappear;
>
> RESULTS:
> - using a mouse the thing works as expected (without scripting where
> configurable) in Chrome, Firefox, Opera, IE from 7 to 11, Edge, Safari
> for Windows (5.1.7), Fennec, Yandex Alpha and the Opera Mobile
> simulator; seems OK on touch screens too, but my choice of testing
> devices is very limited (one Sony Xperia with a 4x5.5 cm screen – I can
> barely see if the text changes; anyway the default browser and Opera
> Mobile do work, Opera Mini and Dolphin do not); definitely fails in IE6;
> - keyboard navigation with javascript enabled behaves as expected in
> Chrome, Firefox and Opera; all version of IE seem to make a large detour
> before landing on the form;
> - keyboard navigation with javascript disabled is definitely subpar;
> - seems OK to me in NVDA, but I'm a beginner with screen readers; I'm
> not sure NVDA does actually react on language changes as it should;
> - the whole site is usable in Linx too, for what it's worth.
>
> That's it. Suggestions and critics welcome, and thanks in advance to
> anybody who cares to take a look.
> --
> -----------------
> Dejan Kozina
> Dolina 346 (TS) - I-34018 Italy
> tel.: +39 040 228 436 - cell.: +39 348 7355 225
> e-mail: <EMAIL REMOVED>
> > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061