Tables

[iuloshi]

Once demo page is built in Capital Framework, per #151.

[Dnpizarro]

@Scotchester has this been developed in FJ? If so can you provide some examples?

[benguhin]

Adding @marteki because she's scrum master and can delegate appropriately

[mebates]

https://pages.18f.gov/govt-wide-patternlibrary/elements/#tables

[caheberer]

Audit of cf.gov tables:

Reversed header, zebra striped, bordered http://www.consumerfinance.gov/mortgage-rules-at-a-glance/

Colored header, no zebra stripes, bordered http://www.consumerfinance.gov/hmda/explore#!/as_of_year=2013&section=summary (generate a summary table to see it)

White header, no zebra stripes, no border

Special case / interactive http://www.consumerfinance.gov/paying-for-college/compare-financial-aid-and-college-cost/

No header, zebra stripes, no border

Gray header, zebra stripes, no border

Updated responsive table currently being used in cf.gov refresh

Highlight interaction

[mebates]

Seems like we should have a standard for border and borderless, ala USDS.

Is there a strong UX argument for the zebra stripes? Is there anyone on cf.gov refresh who can speak to why they were chosen? Looks like USDS is not doing zebra stripes.

[jimmynotjim]

Zebra stripes definitely make it a lot easier to follow along when a table isn't responsive, because you're often scrolling back and forth, but for responsive tables like the Agenda linked above, it's a lot easier because each row is grouped with it's first column as a header and the original table headers are moved inline above their related content.

Now that we have this responsive table pattern, I'm not so sure we need the zebra stripes. @duelj or @ajbush might have compelling reasons to keep them though.

[schaferjh]

After the accessibility training I went through yesterday, I strongly advocate for keeping the zebra stripes. Anything we can do to help people distinguish rows of information is helpful and I don't see a con to keeping the zebra stripe.

[niqjohnson]

Based on all your comments (thanks!), the tables team has taken a first pass at the tables design manual page: http://niqjohnson.github.io/design-manual/ui-toolkit/tables.html.

The examples there aren't fully coded or functional (the sortable table isn't sorting, for example), but hopefully they're far enough along for everyone to get an idea of what we're thinking. Also, there are lots of open questions on the page (in bold) that we'd love feedback on.

One specific item we'd like feedback on: sortable tables. Would those be useful in the first release? What should the sorting icons be (we're aware that the arrows we have there now don't have enough contrast)?

Other than that, how's it looking so far?

[mebates]

Wow, awesome progress!

[niqjohnson]

Some feedback from the Fallingwater design working group on 8/17

• Put the "are" guidance before the "are not" guidance in "Use" section
• Include a section about setting column widths (and how browsers will try to set column widths automagically if widths aren't specified)
• Differentiate header background color in striped tables? Maybe a darker gray? Will that create accessibility issues?
• Consider locking the left column in scrollable tables
• Consider what to do for scrollable tables with really long cells

[ielerol]

This looks great, Niq!

I don't have a good sense of whether sortable tables are important enough for our purposes include in the first release, but I do have some thoughts on the sorting behavior. First, I'd want to make sure the entire header cell is clickable to sort on that column, toggling between ascending and descending. Maybe that's what you intended, but the hover states on the icons make me think that I have to click directly on an arrow to get the table to sort. If we have a hover state I'd definitely want to see it affect the entire cell.

I've looked for some examples of accessible sortable tables, and there aren't a lot of great examples, but I found this one and this one. The icon approach seems to be to show both up and down arrows at high contrast, and then remove the appropriate arrow when the table is actually sorted by that column.

Is there a solid use case for restricting some columns to not be sortable? I can see tables where I wouldn't necessarily care about sorting according to every column, but that doesn't mean it would be a usability problem to allow it. As a default I'd much rather provide the possibility to sort by any column, than assume I can tell when no one will want to sort a particular column.

I like the idea of locking the left column on scrollable tables.

Are we likely to need to combine some of the special cases? For example I'd assume that scrollable tables would also benefit from zebra striping, even with the left column locked. Do we want to be able to use highlighting on a striped table also? We don't necessarily need to show all the options in the design manual, I'm just thinking about potential recommendations for or against certain combinations, and whether needing to combine options will impact the way these are developed.

[niqjohnson]

@ielerol: All good points, thanks!

We're working more on sortable tables now. We'll definitely make sure the sorting trigger is easy to get to and decipher (I think you're right that the arrows are too small to be effective triggers). As for non-sortable columns, the plan for now is to leave non-sorting as an option. I haven't seen any tables currently in use on our sites that would absolutely require non-sortable columns, but I have needed it on past, app-ier projects to handle columns that just have actions (like "remove row") or images to prevent weird sorting.

The special cases are meant to be combined as needed, so a table might have both striping and highlighting. Good idea about having all scrollable tables be striped—we'll take a look at that.

[ielerol]

Oh, good point about non-text content in a table. I've dealt with that before, but in sad legacy apps where sorting was server-side only, controlled by dropdown menus. :disappointed:

[JenniferHoran]

Yes, non text content in a table also needs markup for 508 :)

[jimmynotjim]

Do we have tables without text? Per the spec:

The table element represents data with more than one dimension, in the form of a table.

If it's not text, it's not data, so in situations where there's non-text content we should probably be using a definition list.

[JenniferHoran]

So for 508, think of a table as a grid from a game of battleship. I like to see markup in every cell, even if the cell is blank, because the assistive technology user needs to know where they are in the table. Some kind of markup indicating that this is an empty cell is a best practice even if a visual user would never know that this is there because you've indicated it programatically.

For example if I'm building a table in a Word doc to export to PDF, I type "empty cell" in white text in an empty cell that has a white background, so that the screenreader or AT user will know it is there but the non-AT user would have no idea that the sneaky little markup is included in the empty cells since the white on white text is visually "hidden". If you are using HTML or InDesign or other authoring tools there are other ways of marking up cells, of course. You've probably also seen a dash like "-" in empty cells on a lot of tables people put out, and that is part of the reason why the dash is there, to draw focus on the empty cell so that the AT user knows where they are within the table. You have to know where you are so you can sink that battleship :)

Thanks!

[niqjohnson]

@jimmynotjim, @KimberlyMunoz: I see you two did some work on updating old tables to be responsive in cfpb/cfgov-refresh#308. Did you add data-label attributes by hand on those old tables? If so, do you think that's a good approach for future tables, or would you recommend something more automated, like JS that parses tables and drops in data-labels if they aren't there?

Also, do you have a sense of how accessible the CSS-generated labels are? I'm pretty sure VoiceOver reads content inserted with :before, but not sure about other screen readers.

[KimberlyMunoz]

Did you add data-label attributes by hand on those old tables?

Yep.

If so, do you think that's a good approach for future tables, or would you recommend something more automated, like JS that parses tables and drops in data-labels if they aren't there?

We're discussing that as a possible enhancement at GHE (GHE/flapjack/Modules-V1/issues/8), but it looks like adding data-labels by hand is the safest way for now.

Also, do you have a sense of how accessible the CSS-generated labels are? I'm pretty sure VoiceOver reads content inserted with :before, but not sure about other screen readers.

Screenreaders are iffy on css-generated content, but from what I understand about accessible tables, most of screen readers have built-in ways of dealing with tables and data tables. Since the table headings still exist this shouldn't affect them if the tables are formatted correctly with <th> You can see what the screenreader would dictate below. We should probably test on iOS just in case.

[jimmynotjim]

Ditto what @KimberlyMunoz. @niqjohnson funny that you came to the same conclusion as us, only adding labels if they don't already exist. I didn't realize voice over read the psuedo-content, I thought that was safe for us to add without spamming users with repetitive labels. We'll have to do some testing and document behaviors (which I believe Kim is doing now).

[niqjohnson]

@KimberlyMunoz, @jimmynotjim: Thanks for the info!

I scanned through the FJ module issue on tables, and it looks like we're going in very similar directions. In fact, what's on our draft design manual page is mostly lifted right from the latest FJ code with a few additions to accommodate other tables we found currently in use.

Is there a risk of us duplicating work that the FJ team is already planning on doing?

[niqjohnson]

@caheberer explored some ideas for sorting indicators:

In these ideas, the full column header would be active (i.e. not just the sorting indicator). Hitting a column header once will sort the table by that column in ascending order. Hitting it again will sort in descending order. Depending on how people feel, there could be hover states on not-currently-sorted columns that would give a little hint that the columns can be sorted. The last three ideas use a triangle icon that, I believe, has been talked about as a new minicon.

Any preferences?

[ajbush]

Really nice work you all.

I like the option in the 3rd row with the dark caret. Mainly because it would offer some differentiation between the caret minicon used in the first row. From what I have seen that caret is mainly being used for expandable actions sort of like the "In this section menu" for smaller screens on BETA.

Having a slightly different caret (the solid one in row 3 or another) for sorting would be nice. And we could use the other caret (in row 1) for expandable actions.

[duelj]

One of the fringe cases that we are coming across on FJ and thinking about tables for is what are currently lists of links with multiple downloads. This could be different file types (pdf,csv, etc.) or multiple languages. We have started exploration on solutions that have taken an expandable format but initially we were looking for a table solution. I wondered if anyone here has similar patterns or sees how this might work in one of the table patterns explored above?

[schaferjh]

Apologizes as I'm catching up on this issue after being out, but wanted to respond to two comments in @niqjohnson's first pass http://niqjohnson.github.io/design-manual/ui-toolkit/tables.html --

Under the right aligned columns example, there's a comment about dates formatted ##/##/#### -- FYI on beta, we recently standardized our date format across pages to be MON ##, #### because it's more legible and quicker for users to understand.

Under the pagination example, there's a comment about beta's Activity Log currently being 30 rows per page -- we have been intending to trim this down to 20 rows per page which we felt would be more manageable but haven't had a chance to implement and are open to feedback. When we have filterable post pages (blog, newsroom, many many planned Policy & Compliance pages) we have been limiting to 10 items per page.

[KimberlyMunoz]

I gave the table a test on an iPhone 5S running iOS 9 Preview.

iOS has some built in tools to navigate tables, but they are pretty buggy and require you to go into accessibility options to turn on table navigation and vertical navigation (they aren't defaults). Reading through the table was do-able but didn't really read labels unless we added them with data-label field. Our implementation seems solid.

When I read through the table initially, I just read through them with all the labels by navigating by text (without the special table navigation). It read everything top-to-bottom including the CSS data-labels.

[marteki]

We've incorporated lots of feedback, and the draft recommendation is ready for review by approvers! NOTE: this is a use case and style review, not a code review.

Please look at http://niqjohnson.github.io/design-manual/ui-toolkit/tables.html. Approvers: @nataliafitzgerald @benguhin @Scotchester @JenniferHoran

[Scotchester]

Zebra stripe background will need to be 5% Gray to accommodate linked text, if the color remains Pacific, pending the outcome of this proposed link color update.

[KimberlyMunoz]

We should make a point to call out that we need to use <th> in all data tables, not just the ones we want to have that header bar for accessibility reasons. That's usually how screenreaders tell the difference from data tables and layout tables.

[JenniferHoran]

Thanks Kimberly, yes, we want to make sure it is called out programatically in all data tables. In Word docs, calling it out programatically also makes the table header row repeat when the table runs over a page break :) which is excellent for 508 and usability.

[Scotchester]

Re: "Highlighted rows" add-on:

White on Pacific 80 is not accessible.

[Scotchester]

On sortable tables: Do we ever intend to have tables with some columns that are sortable and some that are not? If so, how do we indicate which ones are/aren't?

[benguhin]

This looks great! The responsive stacked styles and sorting method are really awesome.

You have UI approval to move forward, with two notes:

• I think you should remove the "Highlighted rows" style. Two reasons:
  1. I don't think there's an actual need for it
  2. We should avoid functionality that requires hover states, as over 25% of web traffic is using touch devices, and that percentage will likely grow
• For sortable tables, make sure to define two additional states:
  1. What a sortable column heading looks like when it is not the column doing the sorting
  2. If necessary, any additional highlight for the heading of the column doing the sorting (@keelerr had a good idea to highlight the whole header with background color)

[JenniferHoran]

To close out tables and any 508 comments (I hope this is the right thread, I know we wanted to close out tables discussions this Thursday) I offer the following mini 508 checklist for tables: Never put the table title in a giant merged cell at the top of the table. Avoid complex tables and tables nested in tables, merged or split cells. These all require additional work to support 508. Always markup the table headers. If a table breaks over a page, repeat header row. Every cell should have some kind of markup, even if visually blank, so that an AT user knows where they are in a grid type layout. Think battleship! If you have some kind of table layout with an expand/collapse or toggle button to show more or less info, make sure those buttons are given good naming conventions to link them to what content they belong to, as well as their status. And finally, the all time favorite, do not use color alone to indicate importance or status.

[marteki]

Thanks, we're incorporating the things that were called out.

@nataliafitzgerald, do you have anything to change, or is it a :+1: from you?

[niqjohnson]

Here are the reviewers' changes that we'll be incorporating into the final tables spec (I'll add any other changes to this list as they come in):

• [x] Change column header and stripe background to 5% gray to make sure link text is accessible
• [x] Call out that all data tables need <th>s to be accessible
• [x] Remove highlighted add-on
• [x] Clarify that tables can have sortable and non-sortable columns
• [x] Clarify what sortable column headers that aren't doing the sorting look like
• [x] Possibly add additional highlighting to sortable column headers that are doing the sorting (we're comfortable leaving the arrow as the only sorting indicator for now)
• [x] Adjust spacing in stacked tables to follow 15px/30px standards
• [x] Change header color from Dark Gray to Black
• [x] Specify vertical spacing in stacked base style
• [x] Change stacked entry headers from Avenir Medium to Regular
• [x] Clarify bottom border spec in stacked entry header
• [x] Capitalize color names
• [x] Vertically center sorting indicators
• [x] Check the space between "Use" and "Style" sections (spacing between these sections is the same as on the expandables page; this should be a global change if that's not enough space)
• [x] Check tabular header top and bottom padding (top and bottom padding are equal; maybe it looks off because there are no descenders?)
• [x] Include type styles for label and cell text in "Stacked entry with header" section
• [x] Make sure padding after the rule line in "Stacked entry with header" is 15px
• [x] Remove "any kind of" from intro text
• [x] Lighten the sorting icon? Or use a carrot instead? (we're going to stick with the triangle for now, but let's talk more about this one)
• [x] Make all sortable tables start out with a default sort order?

[nataliafitzgerald]

@marteki - My apologies for straggling. Thanks to Marteki for poking me as I will be out of the office the rest of the week.

This is looking fabulous. My comments are pretty detailed because the big picture is looking great!

• Space between "Use" section and "Style" section is too tight. Double check the code.
• On the "Tabular base style (large screens)" check the padding above and below. The text looks slightly high in the gray box (it may be a few pixels off center).

*For the header on the "Tabular base style" you list the specs as: 14px Avenir Next Demi-bold, all caps, dark gray header text. On the "Stacked base style" you list the specs as: 14px Avenir Next Regular, all caps, black label text. Shouldn't they match?

• In the "Stacked with entry header" (Small screen variations) section you don't include the font specifications for the label and cell text. For the sake of dotting our i's can you add it?
• In the "Stacked with entry header" (Small screen variations) section the space after the rule line (that falls after the Name field) the space feels slightly tight. Try out 15px (it looks like you have 10).
• Change intro text to this: "Tables are used to display data that can be structured into columns and rows." (i.e. remove "any kind of").
• For the sorting icon, I prefer the carrot that you showed in previous iterations. I prefer the carrot minicon for this use case but I understand your reasons for going in the direction of a triangle. Perhaps there is a way to lighten the footprint using color and size to bring it down some. Or, would you still consider using the carrot?

[jimmynotjim]

Spotted this today https://github.com/filamentgroup/tablesaw

[marteki]

Code pull request is live: https://github.com/cfpb/cf-tables/pull/3

[schaferjh]

@marteki @niqjohnson Sorry come back to this -- and I may be misreading the pull request and or Nicholas' page prototype -- but it appears to me that when the "highlighted rows" interaction was removed, no other direction was made about how to indicate interactivity in a table cell/row (links, downloading etc).

Is that correct (and as a result we're leaving interactivity up to individual teams to implement) or am I missing something? Thanks!

[niqjohnson]

@schaferjh: Correct, there's no standard for links/buttons/other click-y things in tables anymore. My thought is that individual teams can style those elements as they see fit, and if a standard starts to emerge from those implementations, we can add it to the Design Manual later.

[schaferjh]

@niqjohnson OK. Thanks for the clarification!

[Scotchester]

Update: cf-tables is live in Capital Framework.

Remaining steps:

• [ ] Add the cf-tables component to the Design Manual's dependencies.
  • This will necessitate transitioning the DM to CF Voltrazord. Shouldn't be toooo much of a pain.
• [ ] Merge in @niqjohnson's content page.

[niqjohnson]

Question I came across while putting the finishing touches on the tables Design Manual page: now that the individual cf-whatever repos are deprecated, where should the repository links at the top of each Design Manual page point to? For example:

Should that "cf-tables" link go to https://github.com/cfpb/cf-tables (like the rest of the pages, even though the first thing you see there is a big old THIS REPO IS DEPRECATED)? Or https://github.com/cfpb/capital-framework/tree/canary/src/cf-tables? Or somewhere else?

[Scotchester]

I think most like it should indeed be https://github.com/cfpb/capital-framework/tree/canary/src/cf-tables

Agree, @cfpb/front-end-team-admin?

[contolini]

@Scotchester :+1:

There's also the gh-pages usage pages but my understanding is that the DM pages will supplant them?

[Scotchester]

@contolini Eventually the DM will have its own code snippets. But there's probably still a value in linking to the source code somewhere on the page, like in that little repository box.

[contolini]

@Scotchester Gotcha. Linking to the capital-framework/src/COMPONENT directories makes sense to me.

[niqjohnson]

And juuuuuuust in time for the end of the sprint, here's the tables Design Manual page with all the new content: http://niqjohnson.github.io/design-manual/page-components/tables.html

And a screenshot just in case:

@kurzn and @sonnakim, how's your new content look in that page?

@caheberer, everything look right to you?

[caheberer]

@niqjohnson looks great to me!

[sonnakim]

@niqjohnson Looks good to me, too! Thanks for taking the time to accommodate all of the new content into the page 👍

One question: would it be a major headache to work in both screenshot examples under the Directory Tables section, as shown below? It would be great to show the larger breakpoint style for comparison.