Use of sScrollX creates duplicate table header id's, causing accessibility WCAG 2.0 A to fail.

sawyerr44

Firstly, would like to say thanks for a great plugin!

I do have an issue that I struggling to resolve ;o(

My table has to conform to WCAG 2.0 AA standard.

I encounter an issue when id’s have been entered into my table header tags and the sScrollX option has been utilised, this combination causes the id’s to be duplicated within the table(s) and therefore causes the accessibility check to fail.

Here is an example of my table source code with the table header tags:

[code]



First Name
Surname
User Type
Email Address
User Name
Telephone Number
Centre Name
Current Status
Action




Joe
Bloggs
Admin
jbloggs@verelogic.com
jbloggs
01793 411111
DAO Administrator
Enabled
Edit Record - Joe BloggsModify User - Joe Bloggs



[/code]

I’m aware that when the sScrollX option is utilised, the table is split into three separate tables, but this is where I encounter my accessibility issue.

When I view the source or view the code in Firebug, the table header has been duplicated in both the dataTables_scrollHead and dataTables_scrollBody, which fails the accessibility check:

“ID must be unique.”

Please find below the output code to showcase this issue:

The first piece of code is the output for the dataTables_scrollHead (I have only cut three table headers as there is a lot of code.)

[code]






First Name


Surname


User Type

[/code]

The second piece of code is the output for the dataTables_scrollBody (I have only cut three table headers as there is a lot of code.)

[code]










[/code]

Your help would be much appreciated.

sawyerr44

Another issue I have noticed is that the ID of the table (in the dataTables_scrollHead section) is removed, which again causes an accessibility issue.

If using the sScrollX option, is there a way of setting different id's for the scrollHead section, so conflicts do not happen with the scrollBody section?

allan

I'm not sure how accessible a table is with scrolling enabled, since it must be split into two sections. Personally, if full accessibility was a primary goal, I would not enable scrolling. It is very unfortunate that the table must be split up for scrolling, but juste just the way it has to be in browsers!

Why is the id being removed an accessibility issue? Also, I agree, there shouldn't be a duplication of IDs, I will look into that, but do you need those ids in the mean time? Could you use some other selector such as a class name?

Allan

wearnshaw

We've been having the same issue on our site.
We have a blind user who has been unable to use the portions of our site that use the datatables since we added the scrolling feature.
Our blind user uses special software to read aloud text on his screen so that he can navigate our website.
I believe the accessibility issue created by removing the ids is that the software is unable to associate the table headers with the data in another table table, even though it is visually very easy to see the association.
We're looking into getting the software he is using so we can test it, but all I know for certain is that as soon as the scrolling option is enabled he can no longer use the page.

wearnshaw

After meeting with our blind user and discussing the problem in further detail we discovered that his screen reader program (JAWS on an up to date mac) selected the datatable as a whole, then would go through the table headers, and then would jump out of the datatable on to the next object in the webpage. It did this regardless of whether sScrollX was being used. We're still working on this, but it seems it has nothing to do with this discussion.

allan

Which version of DataTables are you using? The accessibility with ARIA should be significantly improved in 1.10. However, I'm not a screenreader user myself, so feedback on this topic is _very_ warmly welcomed!

Allan