This is a good idea. How would you handle range sliders?

Tabbing would select rx-pointers which could then be moved with arrow keys. If it's a range slider you would simply tab between the lower and upper rx-pointers. Though it looks like the current implementation hides any unused pointer with z-index: that would have to be done with a proper display: none or equivalent so that tabbing is not disrupted.

With some added aria roles and tab indices this sounds doable to me.

One question is how to handle range slider and aria role, as it looks like the current spec does not accommodated for range sliders, and would involve a duplicate role=slider attribute on both upper/lower pointers. Though an aria-describedby could be used to differentiate the two.

Do you see any difficulties in implementing this?

Would love to have a crack at this (first fork and merge request it would be), but not sure when I'll get the time for it.

Actually, I have never used aria roles so I can't tell you what I prefer. ^^
I'm currently working on a 2.0.0 release that will change the way we pass options to the directive so if you start a fork you should wait this release... It should be done by the end of the day.
This release will break current implementations so I need to provide the correct documentation to help users migrating.

Cool! I'll wait hold the fork, and see what I can cook up.

Looks like mye guess about aria and ranged slider was correct as well: http://oaa-accessibility.org/example/32/

Any feedback on #158 would be great ;)

Do you know if there is another way than setting a tabindex to enable tabbing to an element? Because the tabindex will need to be customizable since we don't know were the slider can be included... If a user is already using tab index for a form and we set default ones for the slider, it can creates problem.

[EDIT]: Actually, setting a value of 0 doesn't change the flow of the document but still enable to focus on an element.

That's right, tabindex=0 would let it follow the normal flow.

The only immediate challenge I see is that each slider dot should have an aria-describedby which would need a unique ID. Any thoughts on how to do that? Also, this describedby text should be customizable so that it can match any language, but I guess a default text value would be acceptable, simply stating “upper/lower”.

alos, #158 looks neat!

If there are two sliders on a page, does each pointer need a unique aria-describedby?
Btw, can you add a +1 on the PR page so I can keep track a each opinion?

any updates here? Are you guys looking to still add keyboard accessibility?

On my side there is nothing done yet but I'll definitely work on it when I get some free time for this library.
If somebody wants to do it, it would be cool as well.

Awesome - I will try to get it done over the next few weeks - as a PR :)

If you have the time, @georgebatalinski go ahead, I havent found the time yet to try it out.

@tommhuth @georgebatalinski any feedback on #191?

I am starting to work on - first setup, I want to setup some unit tests to understand the update flow.

Are you working on a separate PR or looking at mine?

I am on your PR now - #191

It's available with the 2.3.0 release