Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(b-table, b-table-lite): place `<tfoot>` after `<tbody>` element per HTML5 spec and for A11Y #3807

Merged
merged 3 commits into from Aug 3, 2019

Conversation

@tmorehouse
Copy link
Member

commented Aug 2, 2019

Describe the PR

In HTML4 spec, the <tfoot> element must be placed before the <tbody>, while the HTML5 spec states that is must appear after the <tbody> element.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tfoot

The <tfoot> must appear after any <caption>, <colgroup>, <thead>, <tbody>, or <tr> element. Note that this is the requirement as of HTML5.

HTML 4 The <tfoot> element cannot be placed after any <tbody> and <tr> element.

Note that this directly contradicts the above normative requirement from HTML5.

Since all modern browsers support HTML5 spec, and users should have an HTML5 doctype on their rendered page, we should follow the HTML5 spec.

Placing the <tfoot> after the <tbody> also provides better semantic markup flow, specifically for screen readers when a table display has been changed to display: block; via CSS (which removes the normal semantic meaning of table elements). Such is the case with stacked tables (although the <thead> and <tfoot> are visually hidden)

ARIA roles can help (which we do render on all table elements), but there is no differentiation between thead or tfoot via the rowgroup role. tfoot and thead cells have the role columnheader, but again this does not differentiate a header cell vs a footer cell.

By moving the <tfoot> to the bottom of the rendered table, more semantic meaning can be derived solely based on the position of the <tfoot> within the <table>.

Side Note (possibly for future PR):

When a table is always stacked, we do not render the <thead> and <tfoot> elements. perhaps we should be rendering them, but visually hidden. We cannot use the sr-only class mixin, as elements in the tab-sequence would still be reachable, but not visible on screen for visual queues/feedback.

PR checklist

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Enhancement
  • ARIA accessibility
  • Documentation update
  • Other (please describe)

Does this PR introduce a breaking change? (check one)

  • No
  • Yes (please describe)

The PR fulfills these requirements:

  • It's submitted to the dev branch, not the master branch
  • When resolving a specific issue, it's referenced in the PR's title (i.e. [...] (fixes #xxx[,#xxx]), where "xxx" is the issue number)
  • It should address only one issue or feature. If adding multiple features or fixing a bug and adding a new feature, break them into separate PRs if at all possible.
  • The title should follow the Conventional Commits naming convention (i.e. fix(alert): not alerting during SSR render, docs(badge): update pill examples, fix typos, chore: fix typo in README, etc). This is very important, as the CHANGELOG is generated from these messages.

If new features/enhancement/fixes are added or changed:

  • Includes documentation updates (including updating the component's package.json for slot and event changes)
  • Includes any needed TypeScript declaration file updates
  • New/updated tests are included and passing (if required)
  • Existing test suites are passing
  • The changes have not impacted the functionality of other components or directives
  • ARIA Accessibility has been taken into consideration (Does it affect screen reader users or keyboard only users? Clickable items should be in the tab index, etc.)

If adding a new feature, or changing the functionality of an existing feature, the PR's
description above includes:

  • A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)
feat(b-table, b-table-lite): place `<tfoot>` after `<tbody>` element …
…per HTML5 spec

In HTML4 spec, the `<tfoot>` element must be placed **before** the `<tbody>`, while HTML5 spec states that is must appear **after** the `<tbody>` element.  

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tfoot


> A <table> element. The `<tfoot>` must appear after any `<caption>`, `<colgroup>`, `<thead>`, `<tbody>`, or `<tr>` element. Note that this is the requirement as of HTML5.
> > HTML 4 The `<tfoot>` element cannot be placed after any `<tbody>` and `<tr>` element. Note that this directly contradicts the above normative requirement from HTML5.

Placing the `<tfoot>` after the `<tbody>` also provides better semantic markup flow, specifically for screen readers when a table display has been changed to `display: block;` via CSS (which removes the normal semantic meaning of table elements). 

ARIA roles can help (which we do render on all table elements), but there is no diferentiation between `thead` or `tfoot` via the `rowgroup` role. `tfoot` and `thead` cells have the role `columnheader`, but again this does not differentiate a header cell vs a footer cell.

By moving the `<tfoot>` to the bottom of the rendered table, more semantic meaning can be derived solely based on the position of the `<tfoot>` within the `<table>`.
@codecov

This comment has been minimized.

Copy link

commented Aug 2, 2019

Codecov Report

Merging #3807 into dev will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@           Coverage Diff           @@
##              dev    #3807   +/-   ##
=======================================
  Coverage   99.29%   99.29%           
=======================================
  Files         226      226           
  Lines        4401     4401           
  Branches     1251     1251           
=======================================
  Hits         4370     4370           
  Misses         25       25           
  Partials        6        6
Impacted Files Coverage Δ
...c/components/table/helpers/mixin-table-renderer.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ea5d1f...fe310f4. Read the comment docs.

@tmorehouse tmorehouse requested a review from jackmu95 Aug 2, 2019

@tmorehouse tmorehouse changed the title feat(b-table, b-table-lite): place `<tfoot>` after `<tbody>` element per HTML5 spec feat(b-table, b-table-lite): place `<tfoot>` after `<tbody>` element per HTML5 spec and for A11Y Aug 2, 2019

@tmorehouse tmorehouse added Status: WIP and removed Status: WIP labels Aug 2, 2019

tmorehouse added some commits Aug 2, 2019

@tmorehouse tmorehouse merged commit e885d6d into dev Aug 3, 2019

9 checks passed

License Compliance All checks passed.
Details
ci/circleci: build Your tests passed on CircleCI!
Details
ci/circleci: lint Your tests passed on CircleCI!
Details
ci/circleci: setup Your tests passed on CircleCI!
Details
ci/circleci: test Your tests passed on CircleCI!
Details
codecov/patch 100% of diff hit (target 99.29%)
Details
codecov/project 99.29% (+0%) compared to 8ea5d1f
Details
deploy/netlify Deploy preview ready!
Details
security/snyk - package.json (pi0) No manifest changes detected

@tmorehouse tmorehouse deleted the tmorehouse/table-aria branch Aug 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.