Lack of accessibility

[felixzapata]

Hi, there are some issues related with the accessibility with this component and its semantic. Using the basic example:

If you use a screen reader you can't obtain information about the relation between the header with its data (for example, between 'First Name' and 'donna').

Regards.

[Saulis]

Hi @felixzapata!

Yeah, accessibility is something that definitely needs improvements. Would you be able to give some tips on what are the most important features I should be looking into – regarding things like reading data, navigation, sorting / filtering.

I've spent some time reading WAI-ARIA specs but I'm having some problems putting them into practice. Also, I'm not sure how to test the implementation – I mean I can try to use it with OSX VoiceOver but I'm pretty sure that's not enough.

[felixzapata]

hi @Saulis , one of the big problems is the semantyc of the component.

For the screenshot I put before (the basic table), the component visually is a table of data, but internally there are no any tags related with tables (table element, th element, tr element, thead element, tbody element, etc) that are helpful to relate the information. With these elements, the relation between the headers and the data are "natural".

The keyboard access is important too. You have to allow that a user can access to the headers of the component, to change the order or filtered, using the keyboard too (not only the mouse).

Take a look to these videos (if you have not seen yet) of Polymer about how to create accessible components:

• A11y with Polymer - The Polymer Summit 2015
• Accessible Components: Keyboard access -- Polycasts #49
• Accessibility is My Favorite Part of the Platform - Google I/O 2016

[Saulis]

Thanks for the links, they were really helpful. I think I got a good general idea where to start from and how to implement focusing, keyboard navigation and correct semantics.

As you mentioned, the DOM structure doesn't contain a <table> element. This is because of how <iron-list> is built and changing that behavior would require making a fork out of it, which I'm afraid I'm not ready to do at this point. However, I'm under the impression that semantics can be still introduced using the role and aria- attributes?

As an example, I did a simple comparison using <table> element and a group of <div>s using aria-labelledby and role="columnheader attributes. At least when using VoiceOver on OSX I can't see any differences. Please see http://jsbin.com/toripaseme/edit?html,css,output

[felixzapata]

Yes, but that is an example of use of WAI-ARIA as a remedy (as a band aid) instead of enhancement because of a poorly code and unsemantic markup.

The other purpose of WAI-ARIA is to improve the relation between some elements (for example, to inform that a sublist is a popup of elements, etc)

I mean, you should not use the aria attributes to replace the natural behavior of an element. For example, you can create a "button" with an span or a div or whatever other element and use the role="button" for that. But, why don´t you use in that case a button element?

More examples, if you build a "list" of elements with divs (this case is, unfortunately, very common these days) why don´t use a ul or ol for that?

If you are going to show a data table, why don´t you use a table element?.

More useful resources:

• Apps For All: Coding Accessible Web Applications
• Inclusive Design Patterns

My opinion, and it´s totally mine, is that thet use of iron-list in this component is not the most appropiate. The finally of the iron-list is (according to the catalog) to display a virtual, 'infinite' list and in your compontent you are creating a data tables without any relations between the information.

[Saulis]

Yes, but that is an example of use of WAI-ARIA as a remedy (as a band aid) instead of enhancement because of a poorly code and unsemantic markup.

Well... to me the semantics of a plain <table> seem quite limited and using WAI-ARIA with that is more like a necessity than a choice. And as I'm not an expert on this field, I fail to see if an user using some assistive technology can spot the difference between a table made with <table> + WAI-ARIA or with a bunch of <div>s + WAI-ARIA. Now, if there is a difference, I'd like to see it to understand better how things work.

If you are going to show a data table, why don´t you use a table element?

As for using <table>, there are some challenges with the fact that it only allows certain elements like <tbody>, <tr>, <td> etc. inside. That prevents from injecting content from the light DOM inside the shadow container using <content> element anywhere else but separately inside each cell – this caused performance issues at least in the past.

Using <div> elements as rows enable using a single container element for each row which can include a variety of different structures like the row cells and an expandable details view. With <tr> elements, there has to be a new row added with a combination of <td> elements and colspan for each need.

Also, you can't use flexbox with <table>, table-layout: fixed works almost as well though.

My opinion, and it´s totally mine, is that thet use of iron-list in this component is not the most appropiate.

I'd be happy to have a look if you can point out some component that would be more suitable for the job than <iron-list>.

[Saulis]

All that being said, I do have plans to experiment using table in the coming months.

[web-padawan]

There is a known limitation related to the <table> usage: IE doesn't support <template> tags inside it, as well as inside of the <select>.

Look at this component in IE11 and you'll see wtah I mean. At the same time, iron-data-table seems to be OK in IE, at least demos are not broken :+1:

[felixzapata]

@Saulis I am not agree. A data table, like the screenshot before, built with (the correct: th, td, tr, tbody, thead, etc) table elements is fully accessible without the neccesity of WAI-ARIA.

In your previous example of jsbin, a better example for the data table using html table elements, is:

<table>
  <thead>
    <tr>
      <th>Column 1</th>
      <th>Column2</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>foo1</td>
      <td>bar1</td>
    </tr>
  </tbody>
 </table>

It is not neccessary to especify the relations with the headers with the aria-labeledby because, in this case is a simple table, so the table header is enought.

Or, if you want to especify in explicit way the relations between the elements:

Option 1 (you relate the cells with the headers):

<table>
  <thead>
    <tr>
      <th id="table_foo">Column 1</th>
      <th id="table_bar">Column2</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td headers="table_foo">foo1</td>
      <td headers="table_bar">bar1</td>
    </tr>
  </tbody>
 </table>

Option 2 (you relate the columsn with the cells):

<table>
  <thead>
    <tr>
      <th scope="col">Column 1</th>
      <th scope="col">Column2</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>foo1</td>
      <td>bar1</td>
    </tr>
  </tbody>
 </table>

In the three examples, you will using standard (and acessible) HTML. And all of these examples the accessibility is fully, and you do not need WAI-ARIA attributes.

Every time you read information about WAI-ARIA you can find the same information about when you should use and when you should not. I would like you would understand the importance about when you use WAI-ARIA as a band aid.

By the other hand, I'm agree that you want to offer some structures that with the stantard table elements are not easy, so you have to mantein the current markup, but adding WAI-ARIA attributes to improve the accessibilty.

I can't recomender others components. Others components I've seen related with tables or that show tables, do not use other components.

[Saulis]

Maybe I'm doing something wrong, but I can't get VoiceOver with Chrome on OSX to work as (I would expect) without using aria-labelledby attributes.

When navigating to a cell, when using aria-labelledby VoiceOver reads out "Column1, foo1", "Column2, bar1" etc. With all the other combinations described (headers, scope="col", nothing) VoiceOver will read out "foo1, foo1", and "bar1, bar1".

[felixzapata]

mmm, I will check it using this example.

[felixzapata]

I think there is a bug about the tables, in Chrome with VoiceOver, because it works in VoiceOver with Firefox, Safari and under iOS.

[Saulis]

@felixzapata you might want to take a look at the v2.0 of <vaadin-grid>: https://github.com/vaadin/vaadin-grid/releases/tag/v2.0.0-pre.1

We're rebuilding that component from ground up based on the experiences with <iron-data-table>. It has a native <table> DOM structure, and we'll be adding keyboard navigation and other a11y features in the upcoming versions.

For <iron-data-table>, I'm going to keep the current DOM structure as it is, now that I've seen what it takes to implement one using a <table> :smile: I'll try to add aria roles asap.

[felixzapata]

@Saulis after a quick review, it's looks good the v2.0. I will try to isolate the basic example and if I see something extrange I will open an issue in the repository.