Carousel/Slideshow Entity

[ebollens]

@hyperboy and @chris4ucla volunteered to help lead the charge on this one. One of the key drivers here is to create a markup prototype that is fully accessible, as most current implementations right now are not.

[lnicks]

Input directly from @pburkeucla on a 'best case' scenario for behavior.

• slideshow region clearly identified;
• player controls occur before slide objects (Or keystroke commands are listed, even if the buttons themselves are located elsewhere);
• Slide objects should be spoken when they appear on screen.
• The Play/Pause control should start or stop the rotation
• Next & Prev buttons should step thru to the next/prev slide (but ideally this would not restart the scrolling);
• The rotating items should not be spoken when screen reader focus is outside the slideshow area. (Even if the rotating continues, speech prog should ignore it if I'm reading something else on the page.)

The current/most up to date method is to use ARIA's role=application. This let's you restrict the screen reader cursor movement (can only move between the player control buttons).

This also should create more of a "boundary" between the active slideshow region (where special rules apply) & the boring rest of the page (normal rules of screen reading).

[ebollens]

@lnicks @pburkeucla this feedback is awesome!

[spiritcapsule]

I would add for sighted keyboard (non-mouse) users, ensure that player controls are easy to find, easy to reach and visibly highlighted when they have focus.

[lnicks]

We also currently bump up the size of the buttons significantly on mobile breakpoints.

[pburkeucla]

Yes! Sorry I left that out...

Patrick At 10:52 AM 9/17/2013, Chris Patterson wrote:

I would add for sighted keyboard (non-mouse) users, ensure that player controls are easy to find, easy to reach and visibly highlighted when they have focus.

[ebollens]

My proposed markup for this:

<figure class="slideshow">
  <figure>
    <img>
    <figcaption>
  </figure>
  <figure>
    <img>
    <figcaption>
  </figure>
  <figure>
    <img>
    <figcaption>
  </figure>
</figure>

@pburkeucla and I had an interesting conversation about accessible behavior. Let me summarize...

I suggested that the hide used to not display content should take the approach of hide-accessible and the controls should be aria-hidden. As opposed to traditional slideshows, this technique would basically set the slideshow up such that, when viewed on an accessibility device, the figures would appear as though they're just one after another, whereas the presentational view for most devices would be one image at a time with a set of controls to go between them.

Patrick posited the following:

Using a screen reader is not a separate experience in itself. It's using a technology to access a browser on a device. So I should be able to access, in some way, all the functionality of that interface. ARIA's goal, or one of them, is to make this happen."

My counter to this:

As early as 1998, the W3C acknowledged the need to vary presentation via CSS between different user groups. Section 7 of CSS 2.0 specifies a number of media types, including braille, handheld, print and tty. As early as 2004, they (specifically Bert Bos) expanded this definition with a proposal for the reader media type. The CSS 3 Media Queries specification takes this a step further by targeting browsing conditions such as screen size. DOM specifications like the Battery Status Event Specification take this even further, encouraging you to change behavior depending on other conditions as well.

In the use case I'm describing, I'm not saying you don't interact with the set of figures - you just do so differently. The screen reader case isn't a unique case either. Should I not support swipe gestures on a slideshow because desktop devices don't have swipe? Should I not degrade a slideshow to a list of images and captions if one has low battery or Javascript disabled?

Ultimately, I think this arrives us at a question: how far do we go with responsive design?

Put another way: is responsive design just about changing content flow or should we also be changing behavior?

I think this is a question for the group as a whole to discuss.

Of course, the ultimate solution is a conditional that could be set (as another class on the element) to dictate whether you want the behavior to change or not depending on the viewing medium.

[spiritcapsule]

this technique would basically set the slideshow up such that, when viewed on an accessibility device, the figures would appear as though they're just one after another

Not a big deal, but "accessibility device" is probably too general of a term here. I'm pretty sure that if I was more awake, I could think of an "accessibility device" that might see this differently from how a screen reader would.

[spiritcapsule]

A couple of times we've been asked by a client if we can put a video in the slideshow. The slider we were using on Plone allowed for that. The Views Slideshow we use on our Drupal 6 sites and the homegrown slideshow we use on the Drupal 7 sites does not allow for videos.

Also, the slider we used for Plone allowed for text and or html to be on a slide, even without an image.

Both of those alternatives could be very useful.

[spiritcapsule]

and the Plone one allowed for images and text together on one slide. Essentially it was just a block you could configure however you wanted.

[ebollens]

Not a big deal, but "accessibility device" is probably too general of a term here. I'm pretty sure that if I was more awake, I could think of an "accessibility device" that might see this differently from how a screen reader would.

@chris4ucla good catch about the term "accessibility device" - really screen readers and other DOM parsing devices that do not observe the CSS Positioned Layout Module (or equivalent before CSS was modularized).

A couple of times we've been asked by a client if we can put a video in the slideshow. The slider we were using on Plone allowed for that. The Views Slideshow we use on our Drupal 6 sites and the homegrown slideshow we use on the Drupal 7 sites does not allow for videos.

Also, the slider we used for Plone allowed for text and or html to be on a slide, even without an image.

Both of those alternatives could be very useful.

I see no reason we can't provide this. The use of figure, I believe, is still semantically correct, although I'll reconsult the spec to make sure it's still appropriate in such contexts. If not, we might need to use an ordered list instead - but this means that the captioning becomes less explicitly linked.

[ebollens]

Per the meeting, this should support the use of figure > ol > li > figure

[ebollens]

From meeting...

This is a cultural battle.

Great quote from @loganfranken :

There's no one true site

Eric is willing to provide a class for the version that doesn't use hide-accessible - encourage moving into responsive design for devices that don't observe the CSS Positioned Layout Module, but let people have their controls if they want them.