code | 2016-10-22
Tags: Accessibility Aria Components2016-10-22
Switching data providers is tricky, especially when keeping accessible first components
Accessibility in Complex Table Layouts
Summary: Managing assesability throughout a site is tough. Below I talk about our experience switching data providers and no longer have structured data to create accessible tables with. The toughest part of this was associating rows with their parent row, prior to this data provider switch, any cell inside our object, belonged to the parent objects attributes and it was simple to build aria tags. Now, the template object needed to built, but without straightforward associations along with indentations “hierarchy”, font styles “bold”, order to display, Labels and data inside this
Accessible first components
Accessible first is a requirement by our client. Honestly, it's not that hard to implement, one portion at a time. We find patterns, build/re-use modules, and test it thoroughly before handing it off to QA. Though on certain stories, like this one, it added another level of complexity for testing.
Data organization when changing Data Providers
We had to re-design this table because of a data provider change. Essentially, the data we received had an indentation order that needed to be included. Prior to this data provider we had sections, essentially a new section meant a new table and a new th.
Some data points were no longer there, some columns weren’t either, easy, just remove them or replace with the new one. The tough part was the data is now returned in rows, instead of a list of objects (with the table and table header name as properties). Now we could not easily relate columns with their associated table header row, every row thinks it’s related to the top most row in the table. Which isn’t correct and isn’t DA compliant.
Organizing the data similar to how screen readers read it is important. Since we no longer have corelation, we needed to relate the cells data to the headers. For background, we use NVDA and Firefox as our screen reader and ADA compliance baseline. If it works in other browsers or screen readers, great, but we don’t support it.
Example row of data returned from API Row.Bold = n String Row.datapoint = ME23111 String Row.Hierarchy = 3 Int32 Row.name = Income and Expenses String Row.Order = 46 Int32
Another data set held the values for datapoint = ME23111 Row.ME23111 = 12673000000 Double Row.ME23111 = 12648000000 Double Row.ME23111 = 40466000000 Double Row.ME23111 = 0 Double
So combining these two large data sets was our first objective, then creating accessible tables out of it.
Below is a little psedocode for our implementation
If the row is a label, create a new table/tbody and add old table/tbody to a fragment
Otherwise, add data to a new row.
If there is no label, use the header above the table as the caption for this table offscreen text
Create tr with hierarchy, boldness
Create th with scope=”col”
Create td with hierarch, boldness, formatted values If it’s the last item, add the table to the fragment
Below is an example of the output
Challenges we had with testing and accessibility
This page has 12 templates, 3 financial sheet types, 36 tables to test. Checking 2600 lines to be indented, and bold/font-size correctly. To be accessible, we must have structure to each table. A cell must be related to a hr and a td. We no longer always have that header row.
One tough thing I ran into, that you may also run into - The first row doesn’t always have the label and date columns - SQL team could not modify the template to always return the first row as a label, or objectify the data to return it similarly to before.
Several ideas we tried
A single table with many tbody each with their own th rows - We found the association between rows and th tags didn’t work. Use Aria-owns and add ID’s for the th row we wanted associated with a row of data. - Was a lot more work than we imagined, hard to maintain Separate tables each with a
Conclusion of complex accessibility issues
Accessiblity can be difficult, but it’s important to recognize where the problem is. In our case, structuring the data similar to before was helpful, but equally important was to try ideas and test them ourselves. Though implementing and idea and finding out it didn’t work, it helped us learn the best way to approach more complex accessibility issues like this in the future.
We also learned that data organization is important, and even if your API doesn’t support your visual representation, that doesn’t mean it’s outside your ability to implement a solution. There’s always a work around, but it could take more effort and time than you originally thought.