U.S. Web Design System 2.0(v2.designsystem.digital.gov)
v2.designsystem.digital.gov
U.S. Web Design System 2.0
https://v2.designsystem.digital.gov/whats-new/updates/2019/04/08/introducing-uswds-2-0/
47 comments
Almost an exact copy of the UK governments version of this: https://design-system.service.gov.uk/
Some of the markup is incredibly similar. The checkbox stuff[0] looks like a `s/govuk/usa/g`.
I've been working on a GDS project for the last few months, it's actually a nice change to have a set of established patterns to work to and a host of responsive people to discuss extending those patterns with.
[0] https://v2.designsystem.digital.gov/components/form-controls...
I've been working on a GDS project for the last few months, it's actually a nice change to have a set of established patterns to work to and a host of responsive people to discuss extending those patterns with.
[0] https://v2.designsystem.digital.gov/components/form-controls...
honestly good for them, UK gov websites are always very very nice
Dutch government also has its own font.
https://www.rijkshuisstijl.nl/basiselementen/basiselementen-...
https://www.rijkshuisstijl.nl/basiselementen/basiselementen-...
well, we are allies
g105b(1)
As an enterprise software developer who makes software for 'internal' customers, I've not really had to address the issue of accessibility. However, I find this really neat and hope I can be more mindful about it moving forward.
Pretty neat to see how much effort was put into this.
Pretty neat to see how much effort was put into this.
Even for internal apps, it might pay to think about accessibility... e.g. imagine someone who got hired to use the "internal app" was a Marine vet who lost vision to an IED or something... if your company is following the law, you have to provide the same opportunity for him to work there and use that "internal" app as everyone else. Maybe there's some reason why that would never be the case, but devs tend to think of the issue of accessibility much too narrowly.
Thats not entirely accurate. The ADA requires reasonable accommodations, not "the same opportunity". Wether or not making an internal webapp more accessible is reasonable will depend on a lot of other factors.
However, I agree that generally speaking designing your apps to be accessible from the beginning is the right thing to do, and generally results in an easier to use interface for everyone!
However, I agree that generally speaking designing your apps to be accessible from the beginning is the right thing to do, and generally results in an easier to use interface for everyone!
I was considering more "good faith effort" w.r.t. https://www.eeoc.gov/laws/types/disability.cfm but tbh I wish devs would just do the right thing more and less pretend to be lawyers to get away with doing as little as they can to make usable things.
We need easily accessible tools. I used to ignore mobile viewport sizes. Now Chrome has button to emulate smartphone or iPad. I can check my web page with a single click. So I often spend a bit of time to ensure that it at least works good enough in mobile. I did not see anything comparable for blind users. If Chrome developers would add something similar to their developer console, I bet, a lot of new pages will be checked.
There is an incredibly full-featured accessibility audit in Chrome's dev tools:
https://developers.google.com/web/tools/chrome-devtools/acce...
On top of that, there are a lot of Chrome extensions to do all sorts of great things to help you test for accessibility:
ChromeVox - https://chrome.google.com/webstore/detail/chromevox/kgejglhp...
Colorblinding - https://chrome.google.com/webstore/detail/colorblinding/dgbg...
aXe - https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...
Color Contrast Testing - https://chrome.google.com/webstore/detail/color-contrast-ana...
No Coffee - https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbn...
HeadingsMap - https://chrome.google.com/webstore/detail/headingsmap/flbjom...
Wave - https://wave.webaim.org/extension/
ARIA Validator - https://chrome.google.com/webstore/detail/aria-validator/oig...
---
Lack of tools is definitely not the issue.
https://developers.google.com/web/tools/chrome-devtools/acce...
On top of that, there are a lot of Chrome extensions to do all sorts of great things to help you test for accessibility:
ChromeVox - https://chrome.google.com/webstore/detail/chromevox/kgejglhp...
Colorblinding - https://chrome.google.com/webstore/detail/colorblinding/dgbg...
aXe - https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...
Color Contrast Testing - https://chrome.google.com/webstore/detail/color-contrast-ana...
No Coffee - https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbn...
HeadingsMap - https://chrome.google.com/webstore/detail/headingsmap/flbjom...
Wave - https://wave.webaim.org/extension/
ARIA Validator - https://chrome.google.com/webstore/detail/aria-validator/oig...
---
Lack of tools is definitely not the issue.
The axe extension is very nicely done: https://chrome.google.com/webstore/detail/axe/lhdoppojpmngad...
It's also important to keep in mind that some disabilities are temporary.
Someone with normally good vision could have undergone a procedure that leaves them with reduced vision for a while as they recover.
Someone could have a broken hand, or tendinitis, or any number of other temporary conditions that affect precise motion, vision or other physical abilities.
Hell it could be something as simple as they are holding their phone in their other hand and still need to navigate your interface so they have to tab through it with a keyboard instead of using a mouse or trackpad.
These people may still need to use your product during this time when their capacities are reduced in some way.
Accessibility benefits much more than just people with serious and visible disabilities. Accessible applications are better experiences for all users.
Someone with normally good vision could have undergone a procedure that leaves them with reduced vision for a while as they recover.
Someone could have a broken hand, or tendinitis, or any number of other temporary conditions that affect precise motion, vision or other physical abilities.
Hell it could be something as simple as they are holding their phone in their other hand and still need to navigate your interface so they have to tab through it with a keyboard instead of using a mouse or trackpad.
These people may still need to use your product during this time when their capacities are reduced in some way.
Accessibility benefits much more than just people with serious and visible disabilities. Accessible applications are better experiences for all users.
As another enterprise software developer we've been told by legal that we must be accessible per the ADA and that doing otherwise could be used to claim we discriminate (hostile work environment) against our disabled employees.
Title 1:
> Employers must provide reasonable accommodations to qualified applicants or employees. A reasonable accommodation is any modification or adjustment to a job or the work environment that will enable an applicant or employee with a disability to participate in the application process or to perform essential job functions.
With our software handling timecards/leave, inventory, reporting, payroll, etc it isn't realistic for us to claim someone could perform their "essential job function" if it weren't accessible.
That all being said: Our accessibility game isn't perfect. We've just tried to make pages work with screen readers, color-blindness, etc. We still have a lot of internal video content without subtitles however (or even a way to display subtitles).
Title 1:
> Employers must provide reasonable accommodations to qualified applicants or employees. A reasonable accommodation is any modification or adjustment to a job or the work environment that will enable an applicant or employee with a disability to participate in the application process or to perform essential job functions.
With our software handling timecards/leave, inventory, reporting, payroll, etc it isn't realistic for us to claim someone could perform their "essential job function" if it weren't accessible.
That all being said: Our accessibility game isn't perfect. We've just tried to make pages work with screen readers, color-blindness, etc. We still have a lot of internal video content without subtitles however (or even a way to display subtitles).
I'm linking to the recent HN post about Uber's "Based Web" so we can form a linked list of design systems: https://news.ycombinator.com/item?id=19758848 (see insomniacity's comment there for a bunch more)
Also see https://news.ycombinator.com/item?id=18900946 for a similar list (the Australian pendant to this new). I think there was a post about France's, and maybe other non-English-speaking countries, but couldn't find them.
I dislike the fact that only the left half of my screen is used on that web page; the content should at least be centered.
I dislike the fact that only the left half of my screen is used on that web page; the content should at least be centered.
Related: the US government has its own font. The page mentions it further down.
https://public-sans.digital.gov/
Discussion of the font on HN: https://news.ycombinator.com/item?id=19607371
https://public-sans.digital.gov/
Discussion of the font on HN: https://news.ycombinator.com/item?id=19607371
This font is even more interesting because it of its extremely uncertain copyright/licensing situation:
“Open-source licenses, like all software licenses, are only possible through assertion of copyright. Certain free-software advocates prefer to sidestep this inconvenient fact (akin to ‘keep your government hands off my Medicare’). For individual software authors, this usually poses no problem, because their copyright arises at the moment the work is created. Thus, they’re free to put their work under any license, including an open-source license.
“But US government employees are a special case. As a matter of federal law (17 USC § 105), they can’t assert copyright in their work. Public Sans is an inseparable mixture of copyrighted work (= the underlying Libre Franklin font) and uncopyrightable work (= the alterations made by the GSA). The GSA currently claims that Public Sans has been released under the OFL. But that’s impossible. To use this license, they’d first need to have a copyright in their contributions. But they don’t.”
— Matthew Butterick (type designer + lawyer) https://tinyletter.com/mbutterick/letters/the-curious-case-o...
“Open-source licenses, like all software licenses, are only possible through assertion of copyright. Certain free-software advocates prefer to sidestep this inconvenient fact (akin to ‘keep your government hands off my Medicare’). For individual software authors, this usually poses no problem, because their copyright arises at the moment the work is created. Thus, they’re free to put their work under any license, including an open-source license.
“But US government employees are a special case. As a matter of federal law (17 USC § 105), they can’t assert copyright in their work. Public Sans is an inseparable mixture of copyrighted work (= the underlying Libre Franklin font) and uncopyrightable work (= the alterations made by the GSA). The GSA currently claims that Public Sans has been released under the OFL. But that’s impossible. To use this license, they’d first need to have a copyright in their contributions. But they don’t.”
— Matthew Butterick (type designer + lawyer) https://tinyletter.com/mbutterick/letters/the-curious-case-o...
His position is not common and there's a long history of U.S. government lawyers approving participation in open-source projects under licenses which are not the public domain — e.g. SELinux is under the GPL because the original Linux kernel was and the NSA's lawyers approved that contribution.
Here's the upstream issue:
https://github.com/uswds/public-sans/issues/30
He also opened a separate issue claiming an Establishment clause violation because the OFL was created by https://www.sil.org/about:
https://github.com/uswds/public-sans/issues/31
Here's the upstream issue:
https://github.com/uswds/public-sans/issues/30
He also opened a separate issue claiming an Establishment clause violation because the OFL was created by https://www.sil.org/about:
https://github.com/uswds/public-sans/issues/31
The Free Software Foundation doesn't agree that the US government can release software under the GPL. From their FAQ about GNU free software licenses.
>Can the US Government release a program under the GNU GPL? (#GPLUSGov) If the program is written by US federal government employees in the course of their employment, it is in the public domain, which means it is not copyrighted. Since the GNU GPL is based on copyright, such a program cannot be released under the GNU GPL. (It can still be free software, however; a public domain program is free.)
However, when a US federal government agency uses contractors to develop software, that is a different situation. The contract can require the contractor to release it under the GNU GPL. (GNU Ada was developed in this way.) Or the contract can assign the copyright to the government agency, which can then release the software under the GNU GPL.
Can the US Government release improvements to a GPL-covered program? (#GPLUSGovAdd) Yes. If the improvements are written by US government employees in the course of their employment, then the improvements are in the public domain. However, the improved version, as a whole, is still covered by the GNU GPL. There is no problem in this situation.
If the US government uses contractors to do the job, then the improvements themselves can be GPL-covered.
The user space libselinux developed by the NSA is in the public domain. Which is consistent with the above. Are you sure that SELinux contribution was not released as public domain and then incorporated into the linux kernel? Something the GPL allows which the OFL license in question here does not.
>Can the US Government release a program under the GNU GPL? (#GPLUSGov) If the program is written by US federal government employees in the course of their employment, it is in the public domain, which means it is not copyrighted. Since the GNU GPL is based on copyright, such a program cannot be released under the GNU GPL. (It can still be free software, however; a public domain program is free.)
However, when a US federal government agency uses contractors to develop software, that is a different situation. The contract can require the contractor to release it under the GNU GPL. (GNU Ada was developed in this way.) Or the contract can assign the copyright to the government agency, which can then release the software under the GNU GPL.
Can the US Government release improvements to a GPL-covered program? (#GPLUSGovAdd) Yes. If the improvements are written by US government employees in the course of their employment, then the improvements are in the public domain. However, the improved version, as a whole, is still covered by the GNU GPL. There is no problem in this situation.
If the US government uses contractors to do the job, then the improvements themselves can be GPL-covered.
The user space libselinux developed by the NSA is in the public domain. Which is consistent with the above. Are you sure that SELinux contribution was not released as public domain and then incorporated into the linux kernel? Something the GPL allows which the OFL license in question here does not.
I am aware of the Github issue and in fact Matthew has addressed your SELinux point in that discussion. He agrees that if the original font had been licensed under the GPL there would not be an issue here. But the language of the SIL OFL is different than (and incompatible with) the GPL, so the outcome is not automatically the same. And the OSI (the OFL licence's FSF-equivalent) takes the position that public domain and open source don't mix.
Yes, he restated his belief that the U.S. government cannot participate in non-public domain open source projects but he hasn't addressed why so many government lawyers do not share that opinion.
Again, he has said his argument is specific to the SIL OFL and not any other license. The GPL/FSF stuff does not apply to this discussion.
Not sure how he is supposed to have addressed the "lotsa government lawyers think different" argument when no one in that thread has raised it, let alone provided any evidence of it. And again, for it to be relevant, these government lawyer opinions would need to be talking about the OFL specifically.
Not sure how he is supposed to have addressed the "lotsa government lawyers think different" argument when no one in that thread has raised it, let alone provided any evidence of it. And again, for it to be relevant, these government lawyer opinions would need to be talking about the OFL specifically.
> Again, he has said his argument is specific to the SIL OFL and not any other license. The GPL/FSF stuff does not apply to this discussion.
His claim comes down to the U.S. government not being able to use any license which relies on copyright claims, which is not unique to OFL. This is why the government lawyers question is relevant: if he's right, that means that a bunch of other contributions shouldn't have been allowed unless the projects are public domain or dual-licensed.
His claim comes down to the U.S. government not being able to use any license which relies on copyright claims, which is not unique to OFL. This is why the government lawyers question is relevant: if he's right, that means that a bunch of other contributions shouldn't have been allowed unless the projects are public domain or dual-licensed.
> His claim comes down to the U.S. government not being able to use any license which relies on copyright claims
You haven't read his claim then, he explicitly isn't saying that. He claims only that the government can't use the OFL because of the specific demands made by the OFL which the government can't satisfy. FSF licenses don't mind public domain contributions, the same is not true of the OFL.
You haven't read his claim then, he explicitly isn't saying that. He claims only that the government can't use the OFL because of the specific demands made by the OFL which the government can't satisfy. FSF licenses don't mind public domain contributions, the same is not true of the OFL.
Please don't accuse people of not having read something because you don't agree with them.
I'm not sure of the practical implications for someone looking to use it in a design project. Who would have standing to sue for infringement, and in what situations?
I think it's not that someone might now have standing to sue for something and might do it; it's that actually no one has standing to sue even though the GSA is pretending that they do.
If true, the practical implication is that A) Public Sans is in the public domain within the USA, which means people there have freedoms in using it that they wouldn't otherwise have; and B) their current license is incoherently obscuring these freedoms.
The GSA can't license something that is in the public domain. Should they recognize this fact, it will make clear what people can and can't do with the font.
If true, the practical implication is that A) Public Sans is in the public domain within the USA, which means people there have freedoms in using it that they wouldn't otherwise have; and B) their current license is incoherently obscuring these freedoms.
The GSA can't license something that is in the public domain. Should they recognize this fact, it will make clear what people can and can't do with the font.
I came here to say... that body text font renders really nicely on my screen
Is flexbox support sufficiently wide now for public services to adopt it? Or does it rely on good fallbacks?
They have some really impressive documentation in this project. It's really great.
They go over their browser support here: https://designsystem.digital.gov/documentation/developers/
"We’ve designed the Design System to support older and newer browsers through progressive enhancement. The current major version of the Design System (1.0) is designed to support the newest versions of Chrome, Firefox, Safari, and Internet Explorer 9 and up. The next major release (2.0) will follow the 2% rule: we will officially support any browser above 2% usage as observed by analytics.usa.gov. Currently, this means that the Design System version 2.0 will support the newest versions of Chrome, Firefox, Safari, and Internet Explorer 11 and up."
They go over their browser support here: https://designsystem.digital.gov/documentation/developers/
"We’ve designed the Design System to support older and newer browsers through progressive enhancement. The current major version of the Design System (1.0) is designed to support the newest versions of Chrome, Firefox, Safari, and Internet Explorer 9 and up. The next major release (2.0) will follow the 2% rule: we will officially support any browser above 2% usage as observed by analytics.usa.gov. Currently, this means that the Design System version 2.0 will support the newest versions of Chrome, Firefox, Safari, and Internet Explorer 11 and up."
Flexbox support is at 98.59% of global users according to[0] (so probably significantly higher for the US).
[0] https://caniuse.com/#search=flexbox
[0] https://caniuse.com/#search=flexbox
98.59% of general users may not be 98.59% of users in government agencies which is a problem. A lot of users in government agencies are still using Internet Explorer, which makes this question important depending on the audience.
If you are building websites for users of government services its probably ok, if you are building websites for employees of government sites you might have problems.
If you are building websites for users of government services its probably ok, if you are building websites for employees of government sites you might have problems.
Believe it or not, Internet Explorer does support flexbox: both the latest version, and the version before.
There may be more IE users using government sites (whether they be gov employees forced to leverage it for ancient intranet use, or just some older users), but hopefully the number of those on IE <10 will still be extremely small. Global usage for IE <10 is ~0.3%, which includes many users in Asia forced to use IE for ActiveX banking; again, one would hope this figure would be far far lower in the US.
The bulk of that 1.4% of global users without flexbox support are actually more likely to be on an old version of iOS Safari or pre-Chrome Android Browser, than on IE, and desktop would be a larger-than-elsewhere demographic within older users of gov sites, and within gov employees on gov workstations, so in reality the flexbox support stats could well be above average for gov sites.
There may be more IE users using government sites (whether they be gov employees forced to leverage it for ancient intranet use, or just some older users), but hopefully the number of those on IE <10 will still be extremely small. Global usage for IE <10 is ~0.3%, which includes many users in Asia forced to use IE for ActiveX banking; again, one would hope this figure would be far far lower in the US.
The bulk of that 1.4% of global users without flexbox support are actually more likely to be on an old version of iOS Safari or pre-Chrome Android Browser, than on IE, and desktop would be a larger-than-elsewhere demographic within older users of gov sites, and within gov employees on gov workstations, so in reality the flexbox support stats could well be above average for gov sites.
When I was in the military many "trouble shooting" steps for using training portals and similar included step by step guides for how to downgrade Internet Explorer to older versions.
I'm sure with edge around they include steps for how to even find the old Internet Explorer browser on your system.
I'm sure with edge around they include steps for how to even find the old Internet Explorer browser on your system.
There are polyfills in JS available, if you really want to target IE10 and lower.
I get that government websites need to be accessible more then anything, and these constraints are obviously more important then the vague and subjective idea of beauty, but damn some of these components are really ugly:
https://v2.designsystem.digital.gov/components/button/
https://v2.designsystem.digital.gov/components/form-controls...
The borders just seems really poor looking for me. The form controls double borders when in error and focus are so aggressive. No elevations or shadows. It's flat design to it's radical extreme.
I suppose I've gotten used to beauty being subtle - like a good comedy, if it's in your face then it isn't very good.
https://v2.designsystem.digital.gov/components/button/
https://v2.designsystem.digital.gov/components/form-controls...
The borders just seems really poor looking for me. The form controls double borders when in error and focus are so aggressive. No elevations or shadows. It's flat design to it's radical extreme.
I suppose I've gotten used to beauty being subtle - like a good comedy, if it's in your face then it isn't very good.
I wouldn't say they're ugly, more that they're not trendy. They're round rects with text on them.
But I don't need my government services to be on the bleeding edge of web design trends so I think that's fine.
But I don't need my government services to be on the bleeding edge of web design trends so I think that's fine.
The square focus border around the rounded button looks pretty bad to me. I feel like it should be more consistent, either square the button or round the focus border.
IMO having a focus border that doesn't look like a page content element is a feature. You could make it blend in more, but do you really want it to?
I also would have to disagree, I find them to be super easy to understand. And someone like my grand father would actually be able to know whats going on.
This. Accessibility should ideally take into account different levels of information processing abilities. While some of us are happy to sacrifice what we feel is a negligible amount of visual context for visual aesthetic, others may need that extra context and cannot afford such a luxury.
Honestly it looks fine to me - they do seem jarring individually but casually browsing the sites is pleasant.
I'm very appreciative that each component is very clear and pages won't draw my attention in 10 different places.
I'm very appreciative that each component is very clear and pages won't draw my attention in 10 different places.
[deleted]
As an international software engineer living in the US, I'd appreciate if people like Matt Cutts would make an effort towards making non-citizen developers like me to be able to work at US govt institutions like USDS.