Accessibility improvements

[karlgroves]

This adds accessibility enhancements to the table. The only visual change is the addition of a element, which functions as a label for the table. As the table is sorted, the table is updated with a notice.

Test drive it at https://rawgit.com/karlgroves/csv-preview/accessible/example/index.html

[dmaslov]

Hi, @karlgroves !
I think it's cool to implement all this accessibility tricks, but...

1. Could you please tell me what's the idea to use capture tag with information about sorted column and sorted order? Is it important for accessibility, or it's just for fun? :)

• Can we use all this accessibility tricks (like role, scope, aria-*) without capture functionality?
• Or maybe use option to show/hide capture information?
• Or maybe just pass the capture value and show it if it's not empty? I mean without sorting information.

I don't like how it's looks

2. I getting js errors if click just on span element in th. Need to use pseudo class in css instead of nested span element. It's just FYI, I'll fix it after by myself.

3. One more thing. I need .bowerrc with "../" refers to
   made the structure standard #1

Waiting for your response!

[dmaslov]

@karlgroves , I made some updates, could you please resend your pull request if you are agree with my remarks?

[karlgroves]

@dmaslov I added the caption as a means to notify the user about the changes to the table. I think it helps with general usability. For Accessibility APIs, the caption element is used as the "accessible name" for the table. In other words, it functions as the label for the table. Also, I've set it up as an ARIA Live Region.

The Live Region behavior is especially important for screen reader users because even though the other aria-* stuff is on the table headers, screen readers currently don't do anything to announce the changes. They only tell you about the sorted state of table cells when you arrive at the cell. But if you've triggered sorting there's nothing that confirms you've successfully sorted the content. So the caption exists to provide that notice to both visual and non-visual users.

I agree that the visual display of the caption should be optional for implementors of the component. Perhaps an attribute can be added to the element to determine whether to display it or not. But the behavior should be to add or remove a CSS class:

.offscreen{ position: absolute !important; clip: rect(1px 1px 1px 1px); /* IE6, IE7 */ clip: rect(1px, 1px, 1px, 1px); }

So if the implementer doesn't want the visible caption, we add the offscreen class. This will keep the caption element in the DOM but hidden from view.