Open jinky32 opened 9 years ago
Thanks for adding this. I don't think the way Foundation implements accordions is adequate. Each of their items is marked up like this: `
I see no value in the <a>
element here, as it just links to the very next item. I think it's only purpose is to populate (or pollute?) the screen-reader's link list with headings, which is of questionable value.
Their dl/dd markup is basically identical to the above, and they misuse the DL element by omitting the DTs that belong with the DLs (despite having an obvious place to use them).
On the subject of ARIA markup we're basically seeing two approaches: firstly, the addition of ARIA markup to say to the vision-impaired user "We've got an accordion here and this is what it looks like. You have to click this link here to see the content," and secondly, the removal of ARIA markup to say "We've got some headings followed by related blocks of text here". The latter approach is the one I would strongly advocate.
Incidentally I've been working on ways to make accordions better, and I've invented a new technique that uses hardware-accelerated transformations to provide a super-smooth, fast and intuitive interface. Nobody's done anything like that before.
1) Is the HTML structure incorrect and causing issues with screenreaders? GE - I do se a value in the element as otherwise Dragon Naturally Speaking users will not be able to access the area to select. The DL is not really appropriate here I think, as a standard LI will do, it is after all a list of items. You can also style better.
2) Use of tabindex for non-assistive technology users (i.e. those who want to just use keyboard navigation) rather than using href on elements that are not actually links. GE - Do not use tabindex, again as this allows keyboard users to receive focus, but not Dragon Voice Activation users.
3) ARIA landmarks - should / how these be used? Both the above examples make use of various options. GE - Personally using markup that does not rely on ARIA is the best approach as it gives far greater support in AT and other browsers. However, with addition of ARIA it gives meaning to screen readers .
The current offering on 'Foundation' has the following results:
JAWS 16 - IE11 The accordion panel reads to JAWS users as ‘expanded’ or ‘collapsed’ depending on whether it is open or closed. When I press enter to open a panel JAWS indicates that I have entered a form field, when I then try to use the cursor keys to read through the content nothing appears to happen. When user came out of forms mode he was able to access the information.
NVDA 2015 - Firefox Able to interact properly with the accordion in NVDA and Firefox.
iPhone - VoiceOver The accordion works correctly with VoiceOver on iPhone. Be aware of the IOS bug which does not immediately recognise that the accordion is collapsed when activated, the user has to swipe off it and then back onto it so that VoiceOver registers the changed state of the accordion.
Android - TalkBack The user is unaware that the accordions are clickable or whether they are expanded or collapsed. Once expanded the content is read out as ‘accordion’ followed by the number of the accordion which has been activated. The accordions work correctly in Firefox.
Ah it ate my tags was meant to be:
1) Is the HTML structure incorrect and causing issues with screenreaders?
GE - I do se a value in the <a>
element as otherwise Dragon Naturally Speaking users will not be able to access the area to select. The DL is not really appropriate here I think, as a standard LI will do, it is after all a list of items. You can also style better.
Three currently make use of accordions in a number of pages - for example http://www.three.co.uk/Support/Internet_and_Apps/payforit
and
http://www.three.co.uk/moto_maker.
closed![accordion2a](https://cloud.githubusercontent.com/assets/932188/9170831/32888252-3f5e-11e5-968e-4dcc0a0fe6d4.png)
open![accordion2b](https://cloud.githubusercontent.com/assets/932188/9170829/3217efb0-3f5e-11e5-9b9f-e7b952ea41f4.png)
We would like some advice on best practice to make accessible accordions.
I am aware that there has been some discussion of this issue laready via email which I have summarised below:
1) Is the HTML structure incorrect and causing issues with screenreaders? For example the Foundation 5 example is capable of using both dl and li presumably depending on the type of content that the accordion is carrying http://foundation.zurb.com/docs/components/accordion.html and http://foundation.zurb.com/docs/components/accordion.html#accessibility. Whereas some older ones that I have seen previously (for example http://www.oaa-accessibility.org/examplep/accordian1/) only use li
2) Use of tabindex for non-assistive technology users (i.e. those who want to just use keyboard navigation) rather than using href on elements that are not actually links.
3) ARIA landmarks - should / how these be used? Both the above examples make use of various options.