WIA-ARIA usage in tbody
WIA-ARIA usage in tbody
![[Deleted User]](https://secure.gravatar.com/avatar/da384b328badd6f23f9838ae4d4b7149/?default=https%3A%2F%2Fvanillicon.com%2Fda384b328badd6f23f9838ae4d4b7149_200.png&rating=g&size=120)
[Deleted User]
Posts: 0Questions: 0Answers: 0
Can someone explain the logic behind using role="alert" and aria-live="polite" in the tbody tag?
1) The screen reader I'm using to test (ChromeVox plugin) tells the user that the content is an "alert" and I think that's confusing.
2) the aria-live is used to indicate to the screen reader to start reading that content as soon as it has loaded/changed. In this case it causes the screen reader to start reading the contents of the table immediately when the page loads skipping all/any content above it.
Forgive me for being so bold, but I think there might be a misunderstanding by SpryMedia on what these are used for and how they work.
1) The screen reader I'm using to test (ChromeVox plugin) tells the user that the content is an "alert" and I think that's confusing.
2) the aria-live is used to indicate to the screen reader to start reading that content as soon as it has loaded/changed. In this case it causes the screen reader to start reading the contents of the table immediately when the page loads skipping all/any content above it.
Forgive me for being so bold, but I think there might be a misunderstanding by SpryMedia on what these are used for and how they work.
This discussion has been closed.
Replies
Very possibly! Thank you for bringing this up. I'm most certainly open to improving the ARIA attributes DataTables assigns, and to some degree I very much need input on how to most effectively / correctly do that as I don't use assistive technology on a day to day basis myself.
1. tbody role is alert as I felt it was the closest match from the list of standard roles to what the body element was doing. When you change page, it will flag up that the tbody has changed. Perhaps one of the other widget roles would be better, but I could see which. Perhaps you could suggest one?
2. I used aria-live here for things such as changing page, filtering etc. For example, you change page and it will start reading the next page for you. Would that not typically be what you would want?
Perhaps the live attribute should be assigned only once the table has completed its first load to avoid the jump that you mention?
Allan
We are in a similar position to the original poster. Our client is insisting that we support the JAWS screen reader, and when using a bootstrap modal in conjunction with your DataTables, JAWS also reads out the content of the table before reading the content that is above it.
I don't think it necessary to specify a role at all on the tbody element. Perhaps it would be better not to use this attribute at all.
I see your point about using aria-live for paging, filtering, etc. Perhaps your idea of setting the live attribute once the table has completed would work better. In our case, we've commented out that part of your code, since we're implementing our own server-side pagination anyway, we should be able to work around getting the screen reader to read out the new data after a paging event.
Here's an example of what we're trying to do:
[code]
<!DOCTYPE html>
$(function () {
$('a.application-details').on('click', function () {
$("#group-detail-results").dataTable({
bFilter: false,
bLengthChange: false
});
$('#application-details').modal();
$('#main').attr('aria-hidden', true);
});
});
link
Content which should be read before reading the table.
Table heading
Table data
[/code]
Cheers,
Bernie
Adding the live area attribute when the table has completed initialisation sounds like quite a good idea. I will look at implementing this for v1.10.
Regards,
Allan
If a user action causes a change such as a new field to be added, shift ocus to that field.
If a modal dialog suddenly appears, be sure the dialog is marked up properly and then shift focus to it; see this demo:
http://www.mit.edu/~rjc/aria/jQueryTools/dialog.html
Generally, these kind of changes are most likely only known to the application author, not to the plugin author. If live region markup is desired, its usually added by the author using the plugin, not the plugin creator. Of course, rules are meant to be broken, but only if you have a good idea of the consequences...
Hope this helps.
-- Rich Caloggero, MIT ATIC / WGBH NCAM