Add keyboard access to demos to demonstrate accessibility support

[goodmike]

One thing I've noticed about the examples I've checked out is that they are unusable on non-mobile devices without a mouse. I'm personally very interested in making single page applications that are usable by people with disabilities, particularly those using screen readers, and keyboard access is critical to providing this. I don't think it would be hard to make the demos keyboard-accessible, and in many cases it would demonstrate an interesting facet of the framework under examination. For example, here's what I learned about capturing keyboard events in Ember.

I'll volunteer to kick things off with the backbone, ember, and vanilla JS examples.

[sindresorhus]

Big 👍 from me. Can you do a short writeup or example on what needs changing?

The first task would be to agree on the above, then update the app spec and testsuite, so we can ensure new apps adhere to this.

[goodmike]

@sindresorhus Hey, thanks for the thumbs up. I've been considering undertaking this project for a while. I would be happy to write something up to describe what I think should change. Should I post it here, in the issue discussion?

[stephenplusplus]

👍

I think posting it here is fine. That way, concept through plan of action can stay in one place.

Thanks for taking this on, @goodmike!

[goodmike]

Making the demos keyboard-accessible

I would like to propose that keyboard access to all the Functionality listed in the Application Specification should be required of all applications.

Current gaps in functionality

The following features are inaccessible for a user only using the keyboard:

• Edit an Item - Right now only double-clicking will activate editing mode. The text cannot be focused with the keyboard, nor is there any keypress event that will activate editing mode to a focused item.
• Remove an Item - There is no way to make the remove button (.destroy) selectable without moving a cursor over the item.

Proposed game plan

In a nutshell, I'd like to solve the problems above while minimizing the changes to the code in the template and the code changes necessary for existing and proposed applications. The changes should not change the applications' appearance and behavior for mouse users. (The one thing that might change is using a label element for the item text: label elements are not focusable.)

Change the application template

Although the application template is well-structured and uses semantically-rich markup in places, it does not enable keyboard-only users to access all the features the applications are meant to demonstrate.

• Make the items focusable with the keyboard.
• Make the remove button available as the user selects the to-do item's text and then selects the button itself. I think I can do with by tweaking the CSS rules: the application developers shouldn't have to worry about it.

Change the application specification

• Specify that items must remain focusable with the keyboard, as in the template.
• Specify that the text of an item can be put in edit mode with a key press.
  (I propose specifying the ENTER key to enter editing mode as well as to exit it.)
• Specify that the remove button can be activated from the keyboard.
  (This should be provided by the button element normally, but it's worth making the expectation explicit.)

Add browser tests to cover the new requirements in the application specification

• Add tests to assert the new behavior is supported in applications.
• I see you have helper functions in 'browser-tests/page.js' that make the tests themsleves more concise. I'll use those and amend and add helper functions where necessary.

[ColinEberhardt]

Thanks @goodmike - I think this is a fantastic idea. I think accessibility is something that most developers genuinely care about, but lack the skills or experience. Having support for this in ToDoMVC sets a very good example.

It would be very interesting if you could tweak one of the existing implementations to reflect your spec changes. Much easier to understand via a demonstration.

I am guessing that some of the specification will not be testable via automation? It will no doubt require that element focus is visible to the user.

[ivlists]

@ColinEberhardt I dont think automation will require UI element to be mandatorily visible. I guess, if we r using headless browser for automation simulating keyboard events won't be much of an issue.

[ColinEberhardt]

@ivabz I agree, but was thinking the other way around! For the application to be accessible, it must be rendered in a suitable fashion so that focus is clear to the end-user. Automated can be used to test the 'mechanics' of the app, but cannot test whether it is rendered properly.

Regardless, testing keyboard automaton shouldn't be a problem.

[kaleb]

What aria role does a todo list have? To me, role="grid" makes the most sense. Also, only the list as a whole should receive tabindex="0", the individual list items should receive tabindex="-1" and should be selectable with up/down and ctrl+home/ctrl+end buttons. Each list would be a row consisting of three cells: check, item, delete. Enter on check will mark the item as done. Enter on item will toggle editing. Enter on delete will delete. Theses are selectable by left/right arrows and home/end keys.

All list items should have an id to be referenced by the parent's aria-activedescendant attribute.

[goodmike]

Thanks, @kaleb! I'm still very new to supporting accessibility in SPA's and javascript apps generally, and I've had a bit of a tough time finding resources. So, may I ask whether you make these recommendations from personally-gained experience or from some resource or resources? I'd be curious to learn more.

I'd like to get going on this again. I'll look into making your recommended changes, at least to the backbone example, and have my in-house screen reader user try out the results.

[paullewis]

Just wanted to nudge this. I've recently been testing TodoMVC on a bunch of mobile devices, and I noticed (as one example) that you can't get the button (.destroy) because it relies on :hover styles. You have to know to tap on the item first.

It would be lovely to get to some samples that do the right thing here and everywhere else @goodmike has mentioned.

[addyosmani]

@tastejs/todomvc Let's talk about what we can realistically do to include this as part of the spec.

[sindresorhus]

What's the best practise for handling this? Remove the :hover on touch devices? Ideally we would have native effects like being able to slide to delete or something.

[samccone]

I think a fix might require a re-specing of this

[sindresorhus]

Also relevant: tastejs/todomvc-app-css#9

[Frikki]

Any updates on this?

[AutoSponge]

How about a series of puppeteer tests that each project could apply?