xdgov / data-design-standards Goto Github PK

Tried to send this feedback via the suggested "[email protected]" email address, but that email no longer exists. Our developer team was recently pointed to the content in https://xdgov.github.io/data-design-standards/ and I wanted to provide some feedback - mostly related to the use of "aria-label" in the labeling guidance:

<img> elements should use the alt attribute for textual description, not aria-label

<canvas> elements should use content inside the element for textual description not aria-label

For the authoritative reference:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Thinking something akin to the homepage of The Data Visualisation Catalogue or the Data Viz Project.

Add to the CREDITS doc reference links from the prototype's reference site and the google planning doc.

Trello Card: https://trello.com/c/CwGM8JjS/13-add-reference-links-to-repo

Cheers for creating this resource and make it available for public audience!

• Bar Chart
• Box and Whisker
• Bubble Chart
• Choropleth Map
• Dot Distribution Map
• Histogram
• Line Graph
• Pie Chart
• Population Pyramid
• Proportional Symbol Map
• Scatter Plot
• Stacked Bar Chart
• Treemap

The Axes component page implies that interval/tick marks should be included, but wondering if it's worth noting that their omission is also valid when showing trends.

https://en.wikipedia.org/wiki/Sparkline

From @carodew:

be careful with the word ‘standard’ – it has specific meanings in gov and people get VERY UPSET if you use it casually. Which is why WDS recently changed from ‘design standard’ to ‘design system’

More info:

https://designsystem.digital.gov/whats-new/updates/2018/01/17/changing-our-name/

From @abbeykos:

poke through the content guide -- https://content-guide.18f.gov -- some great stuff there about tone, manner, capitalization, etc. you're doing a lot of Camel Case Capitalization and you don't need to do that. more broadly, i'd say to look at https://content-guide.18f.gov/structure-the-content/ and https://content-guide.18f.gov/voice-and-tone/ to help guide your thinking on what will work best for you

uswds/uswds#2326

c/o @maya

https://xdgov.github.io/data-design-standards/visualizations/population-pyramid

That seems to be how they're commonly used, but could it be used to compare other things? Contrived example: number of people (x-axis) in each income bracket (y-axis) for two ethnicities.

This repo should include the following documents to facilitate and encourage contributions:

• Issues Template: .github/ISSUE_TEMPLATE.md
• PR Template: .github/PULL_REQUEST_TEMPLATE.md
• Contributor's Guide: CONTRIBUTING.md

Important dev process notes from my perspective include:

• PRs will be merged using the "Squash and merge" strategy, which incorporates all of the PR's commits into a single commit. This keeps the commit history clean. Note: I've already configured this repo's settings so "Squash and merge" is the only available merge option.
• PRs, before being merged, should be reviewed by an official contributor/admin, hopefully someone other than the PR's main contributor
• PRs, before being merged, should undergo some automatic checks (like CI, when we get there, but also I was hoping to find some platforms in the GitHub marketplace which perform spell checks and content suggestions like "don't use passive voice here")
• I propose we use the labels "ready-for-review" or "not-ready-for-review" to be very explicit about whether or not a PR is ready for review