E-mail List Archives
Thread: New resource showing accessibility problems of dynamic web components in many tests with users (video)
Number of posts in this thread: 3 (In chronological order)
From: Detlev Fischer
Date: Thu, Nov 01 2018 2:39AM
Subject: New resource showing accessibility problems of dynamic web components in many tests with users (video)
No previous message | Next message →
Hi,
I just wanted to make this list aware of a new learning resource, Access
& Use ( https://accessuse.eu ) that covers the accessibility of common
dynamic web components like drop-down navigation, dialogs, tabbed
interfaces, carousels and the like. One important focus was tests with
users with different (dis)abilities, which we have captured on video.
The many short videos have audio description and captions.
The English and German versions are now ready, the French and Swedish
versions are still being translated.
At the end of each component type, there is a section with accessibility
tips. We would be glad to receive feedback on these tips where people
find we give the wrong advice or are missing out on important aspects.
Access & Use was developed within an EU-funded Erasmus+ strategic
partnership project, COMPARE, in which DIAS (Germany) partnered with
BrailleNet (France) and Funka (Sweden).
DIAS intends to keept this resource up and running beyond project
duration. We also intend to add more content as we will conduct more
tests with users in current and future projects. We are also happy to
consider the inclusion of tests recorded by others (it really depends on
how much time it will take to knock videos into shape - if they come
fully captioned (.vtt format) and with built-in audio description,
inclusion is very easy.
Detlev
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
From: glen walker
Date: Thu, Nov 01 2018 3:07AM
Subject: Re: New resource showing accessibility problems of dynamic web components in many tests with users (video)
← Previous message | Next message →
I looked at one, modal dialog, since I had a few minutes and it was the
first one on the list. In your resources section, a nice addition would be
Rob Dodson's a11ycast of modal dialogs.
https://www.youtube.com/watch?v=JS68faEUduk
It's a good video for developers because he shows a lot of code and he
explains *how* to implement all the tips in your list.
One thing that Rob mentions that you don't, and it's more of an
implementation detail to make things easier, is to have the dialog
definition be a "sibling" of the main content. Something like:
<body>
<main>
<!-- your stuff -->
</main>
<div>
<!-- dialog stuff -->
</div>
</body>
The sibling tip shouldn't be an additional bullet point to your list but
rather would be mentioned in the paragraph that describes your point as an
implementation detail, similar to how you have a tip that the dialog should
have a name and one way to implement that is with aria-label or
aria-labelledby.
Having the dialog as a sibling of main helps with your 3rd, 6th, and 7th
bullet points.
Glen
From: glen walker
Date: Thu, Nov 01 2018 3:56AM
Subject: Re: New resource showing accessibility problems of dynamic web components in many tests with users (video)
← Previous message | No next message
Ok, I looked at another one but really need to get to bed (4:00am for me
:-))
Tabbed interfaces, four comments.
1. In the "Realising that arrow keys should be used for focusing tabs"
section, you mention that "Web authors sometimes respond to that usability
problem by making the individual tabs also selectable via the tab key."
This can cause a problem because if the content panel for the currently
selected tab has focusable elements, then they will not be the next
focusable thing immediately after the selected tab. You'd have to tab
through the other tabs in the tablist before getting to the content panel.
Heydon points that out on his page too -
https://inclusive-components.design/tabbed-interfaces/#keyboardbehavior
2. In the "Bypassing visible panel content" section, you say "Another
problem is that screen reader users may bypass the content of the visible
panel, especially if there are no focusable elements in it." In a previous
WebAIM discussion, we talked about not assuming that a screen reader user
will use the tab key to navigate. See
https://webaim.org/discussion/mail_thread?thread=8966. So you may want
to caveat your statement about this problem that if a screen reader is
using the tab key to navigate, then they may miss the content panel if
there are no focusable elements in it.
Also, you say "This is why some authors recommend making the panel
itself focusable
via tabindex". You might have to clarify that. I don't think we want
the panel itself to have a tabindex="0" because you typically don't want a
non-interactive element to receive keyboard focus via the tab key.
However, you could use tabindex="-1" on the panel and programmatically move
the focus to it such as when you hit the down arrow key. Heydon suggests
this too. I just wanted to clarify what you meant by using "tabindex".
That is, tabindex is ok if you're using -1 but probably not ok if using 0.
3. I didn't understand your third bullet point in your tips section.
You said "Use role="presentation" on list elements (li) to which you have
assigned a new role (like role="tab")."
If you used role="tab" then why would you want to override that and then
set role="presentation"? I don't think you're really recommending that but
that's what it sounds like.
I *think* what you're trying to say (and please correct me if I'm
misinterpreting) is that if you are using a <ul role="tablist"> and the
subsequent <li> elements do *not* have a role specified, then you must set
role="presentation" on the list items. However, if the list items have
role="tab", then you're ok.
4. Your first tab example video shows an example from sas.com. I
provided that example way back in May (see
https://webaim.org/discussion/mail_thread?thread=8742#post1) when you
asked for real world tab examples. Yay :-) (I worked for SAS for 30
years.)
Glen