Make slider keyboard accessible

[StommePoes]

Hi, my marketer liked your slider, and asked me to implement it (in a pretty basic way, nothing fancy).

The issue is that this isn't keyboard-accessible, which at the very least would prevent some companies and agencies from being able to use your slider. As a developer I like to ensure some basic accessibility too anyways...

So I've modified our copy of the slider to turn all the clickables into button elements (for the bullets, these are still inside LI elements). These automatically accept keyboard focus, and trigger click events with both enter and spacebar keys.
In addition, I've added :focus styles to the :hover styles.

Some browsers put focus on elements clicked with the mouse, and usually the designers don't want those :focus styles to appear then, so we also happen to use a 2-line mouse-detection script so we can say "only show focus styles when no mouse detected" (could also add touch(start/end) to this as well).

Would you like a pull request?

[jedrzejchalubek]

Hi, thanks for suggestion, but actually this is pretty simple to accomplish with triggers. They were just made for such cases, "if you do not like the default markup".
Here is a demo: http://codepen.io/anon/pen/LVqWwj (styles little broken, but it shows what's going on)

This is a special case for a specific project. I do not want to make it a base, a part of the standard markup. There are few reasons for that:

• Plugin isn't actually markup type sensitive. If you want <button> instead of <a>, just change it.
• Using <button> by default will increase css. They have basic styling from bowser that should by cleared. It's better to use something more neutral.

As I think now, :focus should be added to styling as you point out.

[StommePoes]

(moving my edit to the top)
Edit: Oh, I see what you meant. You just replaced the list with a box of buttons. I kept the list, that's why I made all sorts of changes.

Original message, up to you if you want to read it:

"Plugin isn't actually markup type sensitive. If you want <button> instead of <a>, just change it."

The markup I found was <span> and <li>, not <a>. I clicked for the .zip from the site (not Github), is that out of date? If I made an issue about outdated code, I apologise.
<a>, while being a bit less semantically correct than a button, is otherwise keyboardable out of the box already, no problems. I wouldn't have made an issue over those.

The stuff I changed wasn't really the direction ones (prev/next), you're right that changing the markup to whatever is purely markup there. No problems. But the bullets I did change: because I added children to the li's I shifted the CSS and events from the li's to li.children() etc. I actually only added one property for the buttons, padding. The li styling you have already overrode most of the default browser button stuff (yay).

_:focus styles are great but they only have meaning on focusables, so the bullets, if still only <li> elements, wouldn't do anything.
...Unless you meant maybe "li *:focus" for if any of us add buttons/anchors/whatever as children. That would work.

[ZoeBijl]

“This is a special case for a specific project” accessibility is not “specific” for a “specific project”; it's a universal need and one of the foundations of the internet.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

—Tim Berners-Lee, W3C Director and inventor of the World Wide Web

As stated in the specification:

These are links to other resources that are generally exposed to the user by the user agent so that the user can cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them.

Source: [HTML5 Specification on hyperlinks](http://www.w3.org/TR/html5/links.html#hyperlink) (which `` is)

One could argue that an anchor is the correct element for the purpose of moving to other content in the slider, but then they would have to contain an href linked to an ID (of the slide that is navigated to).

If that is not the case, a <button>-element is more suitable. The use of <li>'s for navigation is only acceptable if you mark them up as buttons and add JavaScript to handle the various keyboard events.

The number of lines you need to capture keyboard events far outnumber the lines of CSS you'll need to style <button>'s the way you want.

Good to hear you will include :focus styles!

[StommePoes]

Sorry @MichielBijl, I had looked at the CodePen but I'm not good at reading pre-HTML thingies and had missed that the buttons were replacing the li's. That means most of the JS changes I made wouldn't even be necessary.

I would still rather that defaults and examples weren't natively non-focusables since developers usually don't bother with changes, but on the other hand the developers who use plugins have the responsibility to change/fix what's needed as well. Again, the li styles I found actually cancelled out most of the default-button stuff, so those weren't too bad either.

[ZoeBijl]

@StommePoes okay, but what about the example on the Glide homepage? That uses <div>'s and <li>'s for the navigation. And there is no keyboard support included.

P.S. you can click 'View compiled' to view the compiled code :)

[StommePoes]

@MichielBijl duh, I'm so not a code-penner. : P

I noticed the examples were different from what you see in the live versions, so they're probably simply out of date. I figure a lot of devs would be inspecting the 2 examples he's got rather than only copying the example HTML... : )

[jedrzejchalubek]

Ok, you convinced me :) I appoint it to the next version. Maybe to that time anyone else terminates.
For now, as i mentioned, it's possible to achieve via triggers without digging into source.

@StommePoes Where are these examples? I don't see outdated ones anywhere.

[ZoeBijl]

👍 Awesome! If you need any help regarding accessibility; you know where to find us.

[StommePoes]

@jedrzejchalubek Hi, on the Docs page under the heading "Setup", you've got an example HTML chunk. Even though developers are encouraged to use whatever markup they need, for many people they're going to see that example and figure it's good enough. I would think probably most people just copy that code and make slight adjustments, rather than writing something entirely new.

But above that part, you've got a running-example slider, the #demo-paddings one. Here, for the bullets you're using something actually invalid (<li>'s can't be children of <div>s, .glide-bullets would need to be a <ul>), but the idea is good -- a list of bullets makes sense just as a list of navigation links makes sense as a list too. I also used the ul-li setup for the main panels too -- which you did on the working-example on the home page #Slider.

So I thought your working examples to be more "updated" than the markup sample under Setup, but that was a guess. Maybe you created them all at the same time :)

In any case, except for the error of div-li, it's a semantics argument. You don't have to do everything in lists. Accessibility-wise, lists have a slight advantage because some Access Technology (like screen readers) can let a user know right away how many items are in a list, which can be handy. But an example composed entirely of divs and buttons can still function properly and can be keyboard-accessible.

So I encourage the lists (ul) you used, but don't demand them.

[jedrzejchalubek]

v2.0.4

[StommePoes]

cooooool :)