The Gov.uk Design System is now live(gds.blog.gov.uk)
gds.blog.gov.uk
The Gov.uk Design System is now live
https://gds.blog.gov.uk/2022/03/31/the-gov-uk-design-system-is-now-live/
135 comments
Some of UX guidance is really good and should be in fact part of the HTML spec.
> Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.
> Do not set the inputmode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator
Also, sad to realise that some of core UX features for HTML, like entering numbers, is so broken three decades later.
> Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.
> Do not set the inputmode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator
Also, sad to realise that some of core UX features for HTML, like entering numbers, is so broken three decades later.
The whatwg.org living standard has a note:
https://html.spec.whatwg.org/multipage/input.html#when-numbe...
> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).
https://html.spec.whatwg.org/multipage/input.html#when-numbe...
> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).
I think browsers messed up the implementation of number by adding increments and spin box things. I wish they would just show a numeric keypad on mobiles, and on desktop restrict input to 0-9, optionally 1 decimal point and an optional '-' prefix, and otherwise present as a normal text box.
If it makes sense for an increment button, it's pretty easy to add with JS, or it could be an optional attribute. I can't remember a case where the increment buttons were useful.
If it makes sense for an increment button, it's pretty easy to add with JS, or it could be an optional attribute. I can't remember a case where the increment buttons were useful.
However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful.
If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases.
I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.
If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases.
I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.
> If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases.
Ideally, yes, we'd have better semantics, but I wouldn't really blame HTML5. In all of computing we don't really have a succinct term for a data type that happens to contain mostly or only numerical digits but isn't actually referring to a numerical quantity (or ordinal, etc.). I see this mistake in software all this time. Someone will add a "social security number" field somewhere as a numerical data type, and some frontend somewhere will format it with delimiters like "123,456,789". Incidentally, that's my goto way to explain the distinction: if you would want to format the number with comma delimiters, it's probably actually a number. Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.
Ideally, yes, we'd have better semantics, but I wouldn't really blame HTML5. In all of computing we don't really have a succinct term for a data type that happens to contain mostly or only numerical digits but isn't actually referring to a numerical quantity (or ordinal, etc.). I see this mistake in software all this time. Someone will add a "social security number" field somewhere as a numerical data type, and some frontend somewhere will format it with delimiters like "123,456,789". Incidentally, that's my goto way to explain the distinction: if you would want to format the number with comma delimiters, it's probably actually a number. Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.
> "Credit cards and phone numbers [...] should not be modeled as numbers."
Agreed that they shouldn't be modeled as a numeric data type. The actual field behaviors are also appropriately implemented for their respective data types in the browsers. I wouldn't so quickly absolve HTML5, though.
The type field describes the purpose of the data, not its 'data type'. Most people consider the term "number" very general and treating it as a special type of value with specific uses and properties is an artifact of software development. HTML isn't a templating language that processes data, and in my experience, many creators and consumers of HTML are not software developers.
The rest of the values are consistent with that intent, maybe except text and to some extent local date and time: Hidden, Text, Telephone, URL, Email, Password, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, Checkbox, Radio Button.
What are the really common uses of "numbers?" Product quantities? Currency? I can't think of much else— certainly nothing people would normally label using the word number. What are very common fields that aren't numbers? Credit card numbers, phone numbers, social security numbers, account numbers, ticket numbers, reference numbers, confirmation numbers...
The label makes sense to people who write application logic using variables where whether something is or isn't a number is really important. To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
Agreed that they shouldn't be modeled as a numeric data type. The actual field behaviors are also appropriately implemented for their respective data types in the browsers. I wouldn't so quickly absolve HTML5, though.
The type field describes the purpose of the data, not its 'data type'. Most people consider the term "number" very general and treating it as a special type of value with specific uses and properties is an artifact of software development. HTML isn't a templating language that processes data, and in my experience, many creators and consumers of HTML are not software developers.
The rest of the values are consistent with that intent, maybe except text and to some extent local date and time: Hidden, Text, Telephone, URL, Email, Password, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, Checkbox, Radio Button.
What are the really common uses of "numbers?" Product quantities? Currency? I can't think of much else— certainly nothing people would normally label using the word number. What are very common fields that aren't numbers? Credit card numbers, phone numbers, social security numbers, account numbers, ticket numbers, reference numbers, confirmation numbers...
The label makes sense to people who write application logic using variables where whether something is or isn't a number is really important. To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
> To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
In some jurisdictions there’s a strong culture of having phone numbers represented as text - so they’re easier to remember. Especially popular for toll free numbers.
I presume that this culture has lead to the popularity of overlaying the alphabet over numeric keypads, for banking machines and payment terminals. As a result, I remember some of my associated pass codes as words, not as numbers.
So there are some real world scenarios where a human thinks a word, while the data item is a number.
In some jurisdictions there’s a strong culture of having phone numbers represented as text - so they’re easier to remember. Especially popular for toll free numbers.
I presume that this culture has lead to the popularity of overlaying the alphabet over numeric keypads, for banking machines and payment terminals. As a result, I remember some of my associated pass codes as words, not as numbers.
So there are some real world scenarios where a human thinks a word, while the data item is a number.
Good call. Definitely all the more reason to avoid using the word "number" to approximate the limiting, specific way developers use it when that doesn't line up with general usage.
I don't think anyone is suggesting that a user interface should refer to a phone number field as "type: text" or whatever. Of course that would be confusing.
It's common enough:
https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description
https://www.w3.org/TR/WCAG20-TECHS/C17.html#C17-description
I’m not sure what you mean. That page isn’t suggesting that you display to the user that the phone number is of type text.
This entire thread is about the type= property of an HTML input field. Nowhere did I or anybody suggest that this be presented on the webpage. The users in question are users of HTML markup, not users of the webpages written in that HTML.
One category I can think of is called "code". Credit card, SSN, could be the same category as zip code. Anything number that does not in calculable semantic (e.g. index, id)
Sounds good to me
> Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.
"Clearly" is debatable. Regardless of how you input the data itself, nothing is stopping you from parsing and encoding it to a valid number of a certain type in a certain range.
Encoding it as something different than numbers seems even more dangerous and I have not seen yet an argument for it that goes beyond the input.
"Clearly" is debatable. Regardless of how you input the data itself, nothing is stopping you from parsing and encoding it to a valid number of a certain type in a certain range.
Encoding it as something different than numbers seems even more dangerous and I have not seen yet an argument for it that goes beyond the input.
Some places have phone numbers that are variable length and can start with a zero. If you store these as numbers, this will drop the leading zero and result in an incorrect phone number.
Phone numbers aren’t numbers. Numerical values can be written as sequences of digits, but not all sequences of digits are numerical values.
Phone numbers aren’t numbers. Numerical values can be written as sequences of digits, but not all sequences of digits are numerical values.
Makes sense.
Maybe a better, clearer heuristic is if leading zeroes change the meaning. For a credit card number, 0002 != 2 therefore a credit card “number” is really a string. For a linear regression calculator, 0002 = 2, meaning you can use the number field here.
I think the real problem is that the heuristic needs to exist. The label "number" makes sense to developers because we have a mental model for the type of data that goes in those fields. However, it excludes many things most non-developers would call numbers, and they are far more common uses for HTML inputs. I don't think it makes sense for that to be a facet of HTML5 when a more appropriate label would do the job.
A phone number is not a number though. It's not an integer. Phone numbers can contain leading zeroes.
I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.'
People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
`number` also unlocks the ability to use a numerical input on a mobile phone. In fact, I imagine this is why there's so many websites using it inappropriately on desktop: because it makes the mobile experience better.
If I was maintaining the HTML spec, I'd do two things:
- Deprecate the use of spinboxes on `number` input. Browser vendors would be free to remove the spinbox or only support it in certain circumstances
- Add an explicit `interface` attribute (or equivalent CSS properties and psuedoelements) for specifying the kinds of input UI the form author expects to be available to the user. You'll be able to apply multiples of these and to any form input type (including <select> and <textarea>) without changing their validation rules. The browser picks out options that make sense for the current platform and input type and implements those.
Interface hints themselves would be things like:
- `keyboard` - widget should support virtual input and/or IMEs (on a select, this would also trigger a combobox)
- `numeric` - implies `keyboard`, plus virtual input should be optimized for numbers (on a phone, this means give the user a numeric keyboard)
- `text` - implies `keyboard`, plus virtual input should be optimized for text of the input widget, document, or user's current language
- `nokeyboard` - widget should not support virtual text input of any kind
- `increment` - widget should have numeric increment/decrement buttons (e.g. use a spinbox)
- `noincrement` - widget should omit numeric increment (no spinbox)
- `content` - contents of the field should be visible to the user (even if the field is type=password; this would allow a "show password" box that does not expose the password to predictive text input)
- `obscured` - obscures the text input like type=password
- `nocontent` - contents of the field are entirely hidden, would allow hiding even the length of a password
- `predict` - widget should participate in predictive text
- `nopredict` - widget should NOT participate in predictive text, and should not have it's input be fed back into the predictive text system, like type=password
- `passwordrecall` - widget should support password recall through a password manager
- `nopasswordrecall` - widget should NOT support password managers
If I was maintaining the HTML spec, I'd do two things:
- Deprecate the use of spinboxes on `number` input. Browser vendors would be free to remove the spinbox or only support it in certain circumstances
- Add an explicit `interface` attribute (or equivalent CSS properties and psuedoelements) for specifying the kinds of input UI the form author expects to be available to the user. You'll be able to apply multiples of these and to any form input type (including <select> and <textarea>) without changing their validation rules. The browser picks out options that make sense for the current platform and input type and implements those.
Interface hints themselves would be things like:
- `keyboard` - widget should support virtual input and/or IMEs (on a select, this would also trigger a combobox)
- `numeric` - implies `keyboard`, plus virtual input should be optimized for numbers (on a phone, this means give the user a numeric keyboard)
- `text` - implies `keyboard`, plus virtual input should be optimized for text of the input widget, document, or user's current language
- `nokeyboard` - widget should not support virtual text input of any kind
- `increment` - widget should have numeric increment/decrement buttons (e.g. use a spinbox)
- `noincrement` - widget should omit numeric increment (no spinbox)
- `content` - contents of the field should be visible to the user (even if the field is type=password; this would allow a "show password" box that does not expose the password to predictive text input)
- `obscured` - obscures the text input like type=password
- `nocontent` - contents of the field are entirely hidden, would allow hiding even the length of a password
- `predict` - widget should participate in predictive text
- `nopredict` - widget should NOT participate in predictive text, and should not have it's input be fed back into the predictive text system, like type=password
- `passwordrecall` - widget should support password recall through a password manager
- `nopasswordrecall` - widget should NOT support password managers
The inputmode attribute does at least some of what you’re looking for: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
(also, why on earth would you choose to block password managers?)
(also, why on earth would you choose to block password managers?)
The only time I can think of when you'd want to block a password manager / form filler is when it gets the heuristic wrong. It's why autocomplete=one-time-code exists.
Things like an admin form in a web app - I might be setting the password for a new user account, but it's not my password, so I don't want my browser to store it.
One-time codes or temporary passwords are another example where the password manager may think it's worth saving, despite being used once.
One-time codes or temporary passwords are another example where the password manager may think it's worth saving, despite being used once.
Your first example is precisely what autocomplete=“new-password” is for:
https://developer.mozilla.org/en-US/docs/Web/Security/Securi...
https://developer.mozilla.org/en-US/docs/Web/Security/Securi...
I don't think the "number" input is nearly as bad as the "time" input...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
This is good advice in practice but I don’t think the HTML spec should be concerned with bad browser implementations. Writing semantically incorrect HTML in order to coax the browser to behave in a certain way should be discouraged by the spec, I would say. Instead, browser vendors should be encouraged to fix their UI.
a lot of web tech is broken like this, but we're all so used to it now that we don't notice unless we really try to.
I've enjoyed reading their thoughtful guidelines for common forms and pages. On the whole, it all seems like good advice that can be applied to any website. They also talk about the pain points and potential research areas. Here's one example https://design-system.service.gov.uk/patterns/gender-or-sex/
[deleted]
bifrosty(1)
https://github.com/alphagov/govuk-design-system-backlog/issu...
am i the only one seeing this tongue-in-cheek thing?
am i the only one seeing this tongue-in-cheek thing?
Based on the issue number, tongue is not in cheek…
and yet im the one being downvoted. this isnt funny
But is it a problem worth solving?
>if your service allows people to jointly apply for something, you might need to refer to both the user and the person they’re applying with. In these cases, use the person’s name, ‘they’ or ‘their’.
This is incorrect. We are talking about government services. Language needs to be precise. There are cases where there is a difference between an individual, a couple, and a group of 3 or more. There is also a very tricky case for non-native speakers and those that are not aware of the culture from which these nuances arise.
The guidance must direct the implementors to use specific language. If confronting a situation in which a pronoun gives rise to ambiguity, do not use a pronoun. So, "if your service allows people to jointly apply for something," define it. Is it "your service allows two people to jointly apply," or "your service allows a group of people to apply," or something else? Using "they" is inappropriate. Something like "you and the other individual" is appropriate.
This is incorrect. We are talking about government services. Language needs to be precise. There are cases where there is a difference between an individual, a couple, and a group of 3 or more. There is also a very tricky case for non-native speakers and those that are not aware of the culture from which these nuances arise.
The guidance must direct the implementors to use specific language. If confronting a situation in which a pronoun gives rise to ambiguity, do not use a pronoun. So, "if your service allows people to jointly apply for something," define it. Is it "your service allows two people to jointly apply," or "your service allows a group of people to apply," or something else? Using "they" is inappropriate. Something like "you and the other individual" is appropriate.
It is not incorrect. Singular they is a perfectly legitimate construction and there's nothing ungrammatical about it. Additionally, if a substantial portion of the population of speakers uses a certain word or construction, then it's no less legitimate than any other. That's how language has always worked, it's defined by usage. What you're calling 'precise language' is language without ambiguities, which simply doesn't exist. Ambiguity is an inevitable part of natural language. You're suggesting that non-native speakers might struggle with it, but as a non-native speaker I can assure you that a pronoun with different meanings depending on context, such as 'they' is an absolute non-issue compared to all the other quirks that natural languages like English have on offer, and always have had.
I think you misread that paragraph. It refers to situations like this: "You selected that you want to jointly apply with another individual. Do *they* live in the same household as you?" Yes, you could also write out "the other individual" every time. The guideline doesn't prevent that. But it says not to use "he" or "she" (or "he/she") to refer to the other individual.
I didn't misread. I like your example. "You selected that you want to jointly apply with another individual." The other person is, grammatically, the third person singular. "Do they" does not agree. The correct form with a pronoun is "Does [3sg]." But we can avoid using a pronoun simply by using the noun.
"Does the other person" is correct, accurately describes the scenario, and is comprehensible at essential English reading levels, which is incredibly important.
"Does the other person" is correct, accurately describes the scenario, and is comprehensible at essential English reading levels, which is incredibly important.
'They' is a third person singular pronoun. It has been in use to denote an singular individual of unknown gender for hundreds of years (since ~14th century).
"With an antecedent referring to an individual generically or indefinitely (e.g. someone, a person, the student), used esp. so as to make a general reference to such an individual without specifying gender"[0]
"Often used in reference to a singular noun made universal by every, any, no, etc., or applicable to one of either sex (= ‘he or she’)."[1]
[0] - https://www.oed.com/view/Entry/200700 - current OED entry
[1] - https://www.oed.com/oed2/00251026 - 2nd edition OED entry from 1989
"With an antecedent referring to an individual generically or indefinitely (e.g. someone, a person, the student), used esp. so as to make a general reference to such an individual without specifying gender"[0]
"Often used in reference to a singular noun made universal by every, any, no, etc., or applicable to one of either sex (= ‘he or she’)."[1]
[0] - https://www.oed.com/view/Entry/200700 - current OED entry
[1] - https://www.oed.com/oed2/00251026 - 2nd edition OED entry from 1989
Funny how people who get wound up about singular 'they' don't have the same issues with singular 'you'.
I would have exactly the same problem. When it is ambiguous, it needs to be clarified. It's easy to write it with clarity. What's the argument for not writing for clarity? This is the fourth time I'm asking, and yet none of the dispassionate, logical people here are willing to address it.
Singular "they" is pretty widely accepted today. Nothing wrong about it. "You" can also be singular or plural.
> Is “they” singular or plural? The answer is both. As of 2019, most big style guides—including the Associated Press, the Chicago Manual of Style, the MLA style manual, and the APA style manual—accept the usage of the singular they. [0]
[0] https://www.grammarly.com/blog/use-the-singular-they/
> Is “they” singular or plural? The answer is both. As of 2019, most big style guides—including the Associated Press, the Chicago Manual of Style, the MLA style manual, and the APA style manual—accept the usage of the singular they. [0]
[0] https://www.grammarly.com/blog/use-the-singular-they/
I agree with you for the purposes of colloquial speech. However, this is formal, and the formality serves a specific purpose.
Somewhat tangentially, we're talking about UK services, and you're citing American style guides. The major British style guides advise against singular "they."
Since we're talking about usability and accessibility, I'm going hammer on the point that this needs to be accessible at baseline reading comprehension levels. Singular "they" is generally not taught either in primary or ESL environments. If it does become part of standard education, we still have generations of people who have not experienced it.
Somewhat tangentially, we're talking about UK services, and you're citing American style guides. The major British style guides advise against singular "they."
Since we're talking about usability and accessibility, I'm going hammer on the point that this needs to be accessible at baseline reading comprehension levels. Singular "they" is generally not taught either in primary or ESL environments. If it does become part of standard education, we still have generations of people who have not experienced it.
"They" uses the plural verb form in pretty much all situations, even if it only refers to a single person. This should be pretty intuitive to most native English speakers - saying "they is cold" is clearly unnatural, but "they are cold" works.
There is an exception for "themselves" - there is some usage of the word "themself" ("they did that themself") but it's fairly uncommon, and most people seem to stick to "themselves" even for a single individual.
It's worth noting that grammar isn't always so concerned with the logic of a situation. For example, German has grammatical gender that, for people at least, matches the gender of the person in question - a male nurse uses masculine articles, a female nurse uses feminine ones. However, a girl (Mädchen) is addressed using neutral articles because the linguistic rule ("-chen" is neuter) overrides the logical rule (female people use female articles).
Finally, it's worth pointing out that, even from a prescriptive perspective, most bodies encourage (or at least allow) the use of the singular they (with plural verb forms).
There is an exception for "themselves" - there is some usage of the word "themself" ("they did that themself") but it's fairly uncommon, and most people seem to stick to "themselves" even for a single individual.
It's worth noting that grammar isn't always so concerned with the logic of a situation. For example, German has grammatical gender that, for people at least, matches the gender of the person in question - a male nurse uses masculine articles, a female nurse uses feminine ones. However, a girl (Mädchen) is addressed using neutral articles because the linguistic rule ("-chen" is neuter) overrides the logical rule (female people use female articles).
Finally, it's worth pointing out that, even from a prescriptive perspective, most bodies encourage (or at least allow) the use of the singular they (with plural verb forms).
> "They" uses the plural verb form in pretty much all situations, even if it only refers to a single person.
This is the problem. I'd like to remind everyone that the context is the usability of a government services website.
> This should be pretty intuitive to most native English speakers
How about non-native speakers?
> most bodies encourage (or at least allow) the use of the singular they
The British style guides advise against it.
I'd ask everyone, rather than repeatedly reminding me that in casual speech we can use different constructions, what is the benefit of using this particular construction in a formal context wherein comprehension is paramount?
This is the problem. I'd like to remind everyone that the context is the usability of a government services website.
> This should be pretty intuitive to most native English speakers
How about non-native speakers?
> most bodies encourage (or at least allow) the use of the singular they
The British style guides advise against it.
I'd ask everyone, rather than repeatedly reminding me that in casual speech we can use different constructions, what is the benefit of using this particular construction in a formal context wherein comprehension is paramount?
Given the amount of user research that is done on the guidance that is added to the design system, I would imagine they've tested it with users and found it works.
It also fits in with their style guide, which talks about writing in a conversational style, https://www.gov.uk/guidance/content-design/writing-for-gov-u...
It also fits in with their style guide, which talks about writing in a conversational style, https://www.gov.uk/guidance/content-design/writing-for-gov-u...
That's not a foregone conclusion. It's an active discussion on their github issue.
Yes, their style guide says to use singular "they," and that's what I'm criticizing. Aside from this particular carve-out, it doesn't really align with their style guide, which offers this advise:
* "To keep content understandable, concise and relevant, it should be incisive (friendliness can lead to a lack of precision and unnecessary words)"
* "You should not let caveats dictate unwieldy grammar"
It's perplexing that so many are insisting on creating a problem. There is a perfect solution that affords gender neutrality and incisive language. Why not use it?
Yes, their style guide says to use singular "they," and that's what I'm criticizing. Aside from this particular carve-out, it doesn't really align with their style guide, which offers this advise:
* "To keep content understandable, concise and relevant, it should be incisive (friendliness can lead to a lack of precision and unnecessary words)"
* "You should not let caveats dictate unwieldy grammar"
It's perplexing that so many are insisting on creating a problem. There is a perfect solution that affords gender neutrality and incisive language. Why not use it?
Singular they is perfectly reasonable in British English. As others have said it is ancient, and modern. It is more of a purcularity that the singluar they ever became unfashionable.
[deleted]
What British style guides? The BBC doesn't mention it (and indeed uses it in their style guide). I don't have the full Oxford style guide, but the online version I've found uses singular they. It's obviously not British specifically, but interesting from the perspective of non-native speakers: the EU style guide also recommends using singular they (and again uses it in their style guide). The GDS is obviously pro singular they!
So I'm not sure where you're getting the idea that British style guides do not support this construction.
I don't think there's a particular benefit to using it, other than that it is a very common and suddenly understood form of English, and in many cases easier to understand than an equivalent, but more complex construction. You talk about using it in a formal context, which to a certain extent this is, but more than that it is important for Government websites to be widely understood - if the Government adopts a register that is too far removed from common English, then they will not be as easily understood. Given that there is no apparent confusion with singular they in conventional speech (and given that, in cases where it is ambiguous, it is possible to find alternative sentence constructions), it seems pointless not to use it.
So I'm not sure where you're getting the idea that British style guides do not support this construction.
I don't think there's a particular benefit to using it, other than that it is a very common and suddenly understood form of English, and in many cases easier to understand than an equivalent, but more complex construction. You talk about using it in a formal context, which to a certain extent this is, but more than that it is important for Government websites to be widely understood - if the Government adopts a register that is too far removed from common English, then they will not be as easily understood. Given that there is no apparent confusion with singular they in conventional speech (and given that, in cases where it is ambiguous, it is possible to find alternative sentence constructions), it seems pointless not to use it.
I've been building prototypes with this. It is everything good web design should be– UI with good contrast, legible type and accessibility patterns.
My only gripe is perhaps if their teams made example pages from their own use cases– sub-nav from the components page, charts/references from their Covid dashboards.
Great work overall!
My only gripe is perhaps if their teams made example pages from their own use cases– sub-nav from the components page, charts/references from their Covid dashboards.
Great work overall!
Not sure if you used the Prototype Kit, but that’s another extremely useful product from GDS: https://govuk-prototype-kit.herokuapp.com/docs
Would love to see how some prototypes look with it if you want to share any :)
Some departments open source all their work, if you're interested in browsing real apps built to GDS standards. I previously contracted at the Office of National Statistics, and it was the case there that everything was built in the open on github. For instance this django app runs all online surveys for the ONS, including the national census! https://github.com/ONSdigital/eq-survey-runner
These are sort of how they started in an afternoon. Then folks were easily able build on top...
https://imgur.com/a/XARRn1n
https://imgur.com/a/XARRn1n
Here's their matching Design System artifact in Figma.
https://www.figma.com/community/file/946837271092540314
https://www.figma.com/community/file/946837271092540314
i love these government design systems.
both the UK gov design system and the US web design system (https://designsystem.digital.gov/). i am always battling with bad UX. that's because i have default settings to help me have a better web experience. once in a while i come across websites designed with care and better experience for the end users. and they stand out.
kudos to the people behind both design systems. you are doing way better than the loud voices we have in the field.
ps: can we get them to adopt a naming convention? (country code + web design system) uswds, ukwds, jpwds, etc...
both the UK gov design system and the US web design system (https://designsystem.digital.gov/). i am always battling with bad UX. that's because i have default settings to help me have a better web experience. once in a while i come across websites designed with care and better experience for the end users. and they stand out.
kudos to the people behind both design systems. you are doing way better than the loud voices we have in the field.
ps: can we get them to adopt a naming convention? (country code + web design system) uswds, ukwds, jpwds, etc...
Very good work.
I’ll definitely be using this on a project we are starting soon instead of tailwind.
Sometimes to move fast one needs opinionated constraints. That’s why bootstrap was so popular and still is.
I’ll definitely be using this on a project we are starting soon instead of tailwind.
Sometimes to move fast one needs opinionated constraints. That’s why bootstrap was so popular and still is.
Coming from Rails, sensible defaults are one thing that I've sorely missed
This is wonderful!
For me, accessibility has always been kind of an afterthought. Not because I don't think it's important but because I don't really have the knowledge of best practices. I hope someone creates a generator for it because I would easily make this my standard front-end for all new projects.
You can check out the code at https://github.com/alphagov/govuk-frontend
For me, accessibility has always been kind of an afterthought. Not because I don't think it's important but because I don't really have the knowledge of best practices. I hope someone creates a generator for it because I would easily make this my standard front-end for all new projects.
You can check out the code at https://github.com/alphagov/govuk-frontend
As a UK taxpayer reading this gives me a rare feeling of being proud of where my money is going.
Always I go to any .gov.uk website I only feel envy comparing it to the .gob.es I need to deal with from time to time.
gov.uk is the best, consistent, and usable government portals I have ever used. Kudos to GDS on their work and transparency.
Better than most.
I'd recently complained about my local Council (in the UK) failing to provide accessible information.
If you're into horror shows then feel free: https://eyesiteview.co.uk/galacampus/informal-consultation/e...
It previously used to 301 if you were on Linux and a whole host of other user agents saying "you cannot view this page due to incompatibility".
After 30 years of the web, publicly funded information should be available to all.
I'd recently complained about my local Council (in the UK) failing to provide accessible information.
If you're into horror shows then feel free: https://eyesiteview.co.uk/galacampus/informal-consultation/e...
It previously used to 301 if you were on Linux and a whole host of other user agents saying "you cannot view this page due to incompatibility".
After 30 years of the web, publicly funded information should be available to all.
It's awful! The VR navigation is already nonsense, but the cherry on top is clicking one of the info bubbles and then being presented with a framed PDF document.
Would be nice if they'd get around to developing a standardised calendar-based date picker component for, say, appointment booking at some point.
Feels like a huge gap in their offerings.
Feels like a huge gap in their offerings.
IIRC this is something they’ve investigated for years, but the prototypes didn’t stand up to a simple day/month/year input group in usability testing. Date pickers are hard to do well!
While we’re discussing datepickers, the new iOS one annoys me. When I have to put in my birthday, it defaults to the current date and wraps any value past that back to today. So I put in my day and month of birth, have it wrap back to today and then start again by setting the year first.
I assume this is configurable and developers just forget to set it, but it’s a weird default.
I assume this is configurable and developers just forget to set it, but it’s a weird default.
I really dislike calendar inputs, they are almost always confusing to use. Their inconsistencies moreover lead to further confusion as each calendar seems to be very different.
It's on their backlog: https://github.com/alphagov/govuk-design-system-backlog/issu...
Would definitely be nice to have
Would definitely be nice to have
I understand that there are high WCAG compatible demands but overall design vise, it seems a bit poorly balanced and sometimes confusing. Not bad, not great. The animations though… Please remove. Also remove underlines from heading like elements. If there is a confusion in the context if a heading is clickable or not underlines only adds to that confusion.
Which animations are you referring to? I don't think I can find any components with animations in the GOV.UK Design System <https://design-system.service.gov.uk/>.
Likewise for underlines on headings – I can't see that in the style guide.
Likewise for underlines on headings – I can't see that in the style guide.
The animation when you click links. I was thinking that they are dogfooding and the blog has those types of headings.
This is what it looked like in 2017.
https://web.archive.org/web/20170119063846mp_/https://www.go...
https://web.archive.org/web/20170119063846mp_/https://www.go...
I'm a little disappointed that gov.uk has custom date inputs specified.
I think it's time for web sites to stop doing custom date inputs. Even Safari finally has a native date input.
The worst are the sites that make you enter a day from a drop-down menu.
Second-worst are the ones that are asking for your birth date as input, but the default drop-down for the year is the current year. As if a six-month-old baby is signing up for a car loan.
Third-worst are the ones that make you pick a day from a drop-down. Bad programmers do this because they're bad at input validation. Well, with your drop-downs I can enter February 31. So now you've got two problems.
I once saw a government web site that had you pick each number from the date input as a separate drop-down. Who builds these things?
I think it's time for web sites to stop doing custom date inputs. Even Safari finally has a native date input.
The worst are the sites that make you enter a day from a drop-down menu.
Second-worst are the ones that are asking for your birth date as input, but the default drop-down for the year is the current year. As if a six-month-old baby is signing up for a car loan.
Third-worst are the ones that make you pick a day from a drop-down. Bad programmers do this because they're bad at input validation. Well, with your drop-downs I can enter February 31. So now you've got two problems.
I once saw a government web site that had you pick each number from the date input as a separate drop-down. Who builds these things?
I agree some of the choices are questionable, but they have done quite a bit of research in reaching what they currently use:
https://github.com/alphagov/govuk-design-system-backlog/issu...
https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...
https://github.com/alphagov/govuk-design-system-backlog/issu...
https://github.com/alphagov/govuk-design-system-backlog/issu...
https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date...
https://github.com/alphagov/govuk-design-system-backlog/issu...
But, they didn't test the native date inputs, just drop-down and text options. So my point stands for now.
At least they do research and document. Thanks for those links.
I build my web sites based on first- and third-party research, but work in an organization stuffed with managers who want our sites to look more like TikTok, because that's what they spend most of their time on, and think we don't look like a real company if we don't have pop-ups and garrish colors, and things flying around the screen. We're a healthcare company.
I had one manager tell me that the company's web site didn't look like a "real" web site because it didn't have lots of little placeholder spinners. Explaining that they're not needed because the page loads in under a second got me a look like when you're trying to explain temporal physics to a collie.
At least they do research and document. Thanks for those links.
I build my web sites based on first- and third-party research, but work in an organization stuffed with managers who want our sites to look more like TikTok, because that's what they spend most of their time on, and think we don't look like a real company if we don't have pop-ups and garrish colors, and things flying around the screen. We're a healthcare company.
I had one manager tell me that the company's web site didn't look like a "real" web site because it didn't have lots of little placeholder spinners. Explaining that they're not needed because the page loads in under a second got me a look like when you're trying to explain temporal physics to a collie.
The short answer is that the native date inputs aren't accessible. They don't work nicely with all assistive technology like JAWS.
There's more of a discussion here
https://github.com/alphagov/govuk-design-system-backlog/issu...
There's more of a discussion here
https://github.com/alphagov/govuk-design-system-backlog/issu...
Even Safari finally has a native date input.
A deeply flawed one. https://twitter.com/jaffathecake/status/1509447655579176963
A deeply flawed one. https://twitter.com/jaffathecake/status/1509447655579176963
Safari on iOS has trouble with blank date inputs (when date is optional).
My workaround for reliable date entry UI was to have a <input type=text> for date entry, with a second <input type=date> to the right of the text but that styled as a square dropdown icon, with tabIndex=-1, and JavaScript code to sync the two inputs. That allowed typing in the date, and also allowed users to use the browser native date input entry without forcing users. That avoided problems with broken user agents (mobile or desktop or OS).
My workaround for reliable date entry UI was to have a <input type=text> for date entry, with a second <input type=date> to the right of the text but that styled as a square dropdown icon, with tabIndex=-1, and JavaScript code to sync the two inputs. That allowed typing in the date, and also allowed users to use the browser native date input entry without forcing users. That avoided problems with broken user agents (mobile or desktop or OS).
The gov.uk research lined to above seems to indicate this isn't unique to Safari. Hopefully all the browsers and input shims will figure this out soon.
Component under discussion: https://design-system.service.gov.uk/components/date-input/
It is bad. Day month year are separate inputs. No auto-jump to next input. Even if this was done for accessibility reasons, it is not accessible for many on the a11y spectrum.
Also, the component is half baked. How come one can input wrong input and there is no immediate error feedback? How come the error example still shows a validation error despite entering correct data?
It is bad. Day month year are separate inputs. No auto-jump to next input. Even if this was done for accessibility reasons, it is not accessible for many on the a11y spectrum.
Also, the component is half baked. How come one can input wrong input and there is no immediate error feedback? How come the error example still shows a validation error despite entering correct data?
> It is bad. Day month year are separate inputs. No auto-jump to next input. Even if this was done for accessibility reasons, it is not accessible for many on the a11y spectrum.
Auto-advancing is a non-standard behavior for input fields, it could easily be confusing for users who aren't expecting it. Behavior in auto-advancing fields can also be awkward when going back to edit values, or pasting. I also wouldn't be surprised if it was more difficult for a11y users with screen readers. Keep it simple.
> Also, the component is half baked. How come one can input wrong input and there is no immediate error feedback?
This is covered elsewhere under "Patterns / Validation" [0], they recommend delaying validation until the user attempts to move on to the next section or submit the form.
> How come the error example still shows a validation error despite entering correct data?
I'm not sure what you mean, both examples have clear explanations in the error message; the first example [1] indicates that the date must be in the past and the second [2] is missing the year.
0: https://design-system.service.gov.uk/patterns/validation/#wh...
1: https://design-system.service.gov.uk/components/date-input/e...
2: https://design-system.service.gov.uk/components/date-input/e...
Auto-advancing is a non-standard behavior for input fields, it could easily be confusing for users who aren't expecting it. Behavior in auto-advancing fields can also be awkward when going back to edit values, or pasting. I also wouldn't be surprised if it was more difficult for a11y users with screen readers. Keep it simple.
> Also, the component is half baked. How come one can input wrong input and there is no immediate error feedback?
This is covered elsewhere under "Patterns / Validation" [0], they recommend delaying validation until the user attempts to move on to the next section or submit the form.
> How come the error example still shows a validation error despite entering correct data?
I'm not sure what you mean, both examples have clear explanations in the error message; the first example [1] indicates that the date must be in the past and the second [2] is missing the year.
0: https://design-system.service.gov.uk/patterns/validation/#wh...
1: https://design-system.service.gov.uk/components/date-input/e...
2: https://design-system.service.gov.uk/components/date-input/e...
The issue is that most native date input pickers use a calendar, which is not always useful for some situations. If I'm planning a vacation, picking start and end dates, sure that could be handy. But if I'm entering something like my birthday, how does the calendar help me? It doesn't really help me to know that I was born on a Tuesday. There is one specific correct answer that I know by heart, I'd rather input it directly than page back in time a few decades and find the right square to click on.
I agree with the Design System and I apply simplicity and user centric design throughout my sites as well, for example at Ypson [1], I also advocate for this through Leanternet [2]. Wish more people would go against the flow of multi megabytes sites with large hero images and endless frameworks, worst offenders being the ones who load entire frameworks to just display a few lines of text.
Please, focus on the user as your primary goal of your website, the rest is fluff and can be trimmed. Thank you!
[1] https://www.ypson.com [2] https://www.leanternet.com
Please, focus on the user as your primary goal of your website, the rest is fluff and can be trimmed. Thank you!
[1] https://www.ypson.com [2] https://www.leanternet.com
A big success. I am impressed by the quality of UK go websites.
Well done. Someone should share this with the current Stack Exchange designers, since they don't know what the hell they are doing.
Tabs in smartphone screen size portrait mode looks wrong, e.g. tablist presentation is different, and the tabs container has no visual wrap: https://design-system.service.gov.uk/components/tabs/default...
How do you mean wrong? It's meant to look like a small table of contents that links to the relevant subheading beneath.
It's wrong because tabs are not meant to be presented as a small table of contents.
Viewing the same page in landscape mode/bigger screen does show tabs.
Tabs are meant to be presenting only the currently selected option, one reason for that being concise in a constrained environment.
Their tabs implementation does the wrong/opposite thing when it is the most useful (small screen).
Also, it is confusing to have a completely different presentation depending on screen size.
Viewing the same page in landscape mode/bigger screen does show tabs.
Tabs are meant to be presenting only the currently selected option, one reason for that being concise in a constrained environment.
Their tabs implementation does the wrong/opposite thing when it is the most useful (small screen).
Also, it is confusing to have a completely different presentation depending on screen size.
Rendering them inline might not be ideal but user research has shown that having more than a couple of tabs on mobile leads to problems. They are exacerbated when the tabs wrap on to multiple lines - or heaven forbid, require horizonal scrolling.
From a usability point of view rendering the content online makes sense.
It has the added benefit of working well for people who have disabled JavaScript too.
From a usability point of view rendering the content online makes sense.
It has the added benefit of working well for people who have disabled JavaScript too.
I enjoy using gov.uk services and it is due to this cohesive clean style. It is not perfect, example: I’ve encountered long questionnaires that show just one question per page so it feels endless and unrelenting, however it is reassuring to know that my parents and other demographics could comfortably access the same services.
Hi, is there a wordpress theme with this design system that we could drop in an existing website and benefit from it?
The GDS is fundamentally the best UX team I’ve ever seen in the wild delivering large projects consistently.
An aside: Assuming that page was authored using the design system... can anyone tell me why the leading/margin above a heading is shorter than that below it.
To me it makes the headings appear to be more connected to the paragraph above them than below, messing with my semantic overview.
To me it makes the headings appear to be more connected to the paragraph above them than below, messing with my semantic overview.
I've noticed this on the blog too. The Design System itself has better spacing.
Take a look at this page as an example:
https://www.gov.uk/guidance/living-safely-with-respiratory-i...
Take a look at this page as an example:
https://www.gov.uk/guidance/living-safely-with-respiratory-i...
That’s more what I expected. Thanks!
I've been using Carbon Design System for the consistent look and feel, but there is a lot of good content on this that can be applied as well.
Each component describes when you should use it, how to do things, and considers accessibility from all angles.
I'll be having a red through later!
Each component describes when you should use it, how to do things, and considers accessibility from all angles.
I'll be having a red through later!
Why does it have a icon at the bottom left corner for cookie agreement, I have made the decision when I visited it for the first time?
I despise GDS Transport. A font deisgned to remind you of your powerlessness. The symbols of oppression.
The design system that launched in 2018 and went 'live' in Nov 2021, is now....live? Sure ok
Still legends.
Still legends.
Any gov services must go through very detailed assessments. Quite often moving from "public beta" to "live" takes years - lots of data is required.
So yes, they did only just go live, they were in beta :)
So yes, they did only just go live, they were in beta :)
How does this compare to the US one? Thinking of using one for my next project
I am personally extremely repulsed by UK GDS. It is tremendously bloated, there is no visual cohesiveness and negative space is liberally applied everywhere. Typography is haphazardly sized. Not sure why people think this is a good trend.
It is possible to design compact, well functioning and accessible design frameworks. UDWDS is far better in this regard: https://designsystem.digital.gov/
It is possible to design compact, well functioning and accessible design frameworks. UDWDS is far better in this regard: https://designsystem.digital.gov/
Is Nunjucks a thing now? First time I hear about it.
Realistically, it's just Jinja2 ported to js. If you've ever worked with Django or flask it's very quick to pick up.
Its been there ever since nodejs was around. Ive been using it for a long time now. I love it as a template engine.
I like this vs the US designs.
Which aspects of this one do you prefer over USWDS?
Well, if you don't like our government's design system you might as well leave the country! /s
What do you like about this more? The visuals, the documentation, the guidelines, the code?
What do you like about this more? The visuals, the documentation, the guidelines, the code?
Why does the sticker in the photo say "GOV.UK Design System — Live 19 November 2021"?
Potentially related to the quote: “As it turns out, we did not pass our live assessment the first time.”
Glad to finally see gov design finally getting close to private industry!
There is so much praise in this comment section, that I gotta be the grumpy negative guy:
It isn't good yet:
* The brutalist/minimal style is so reduced yet blown-up I find it confusing to grasp sections. E.g. on first visit (incognito) visiting https://design-system.service.gov.uk/styles/ all this monster cookie notice, footer, whitespace leaves the actual content maybe just 10 percent on a regular desktop screen.
* Tables ( https://design-system.service.gov.uk/components/table/ ) are so minimalistic (no vertical column separators, no color shading to context, no visual scrollability hints), plenty of scenarios exist where visually reading tables becomes hard. You need visual separations between columns when the header is far away (and non-sticky). Also, all this empty table void does not communicate to mobile / small screen users that they can horizontally scroll tables. The mini examples on https://design-system.service.gov.uk/components/table/ don't show these apparent issues.
* Would you have guessed "HTML"/"Nunjuck" have tabbish behavior and reveal content on-page on click? They look like regular navigational links.
* HTML code is way too verbose and there is plenty of unnecessary nested div soups. What is the need for `class="govuk-footer__meta-item govuk-footer__meta-item--grow"`? Do you need to be so specific? (Hint: you don't; a wrapper class is often enough for any further (CSS/JS) matching). https://design-system.service.gov.uk/components/footer/
* Does not allow more than one skip link ( https://design-system.service.gov.uk/components/skip-link ), as they are visually overlapping.
* https://design-system.service.gov.uk/components/inset-text/ There are dedicated HTML elements which semantically fulfill this div component's purpose (`blockquote`, `aside`...)
* File upload component: No value added to what browsers have out of the box ( https://design-system.service.gov.uk/components/file-upload/)
* Buttons and color: No matter if default (green), secondary (grey) or warning (red): the moment these buttons receive focus, they all get the same focus color yellow, thereby no longer communicating their intent visually.
* Accordions, they are just confusing: where does a accordion's content start and end? Put some borders around it. The over-the-top focus highlight adds to this confusion https://design-system.service.gov.uk/components/accordion/
* ... Which brings me to the last point: The screaming focus yellow highlight. This and other stuff in this design system is bleeding-edge accessibility conformity: crank accessibility to 150%, help some with it, but also leave others confused by it. Maybe think about `:focus-visible` instead of `:focus`. But hey, Chrome Lighthouse gives 100/100 ;-). To end on something positive, I checked with NVDA and keyboard input superficially (e.g. search box) and accessibility/ `aria-` markup looked fine.
It isn't good yet:
* The brutalist/minimal style is so reduced yet blown-up I find it confusing to grasp sections. E.g. on first visit (incognito) visiting https://design-system.service.gov.uk/styles/ all this monster cookie notice, footer, whitespace leaves the actual content maybe just 10 percent on a regular desktop screen.
* Tables ( https://design-system.service.gov.uk/components/table/ ) are so minimalistic (no vertical column separators, no color shading to context, no visual scrollability hints), plenty of scenarios exist where visually reading tables becomes hard. You need visual separations between columns when the header is far away (and non-sticky). Also, all this empty table void does not communicate to mobile / small screen users that they can horizontally scroll tables. The mini examples on https://design-system.service.gov.uk/components/table/ don't show these apparent issues.
* Would you have guessed "HTML"/"Nunjuck" have tabbish behavior and reveal content on-page on click? They look like regular navigational links.
* HTML code is way too verbose and there is plenty of unnecessary nested div soups. What is the need for `class="govuk-footer__meta-item govuk-footer__meta-item--grow"`? Do you need to be so specific? (Hint: you don't; a wrapper class is often enough for any further (CSS/JS) matching). https://design-system.service.gov.uk/components/footer/
* Does not allow more than one skip link ( https://design-system.service.gov.uk/components/skip-link ), as they are visually overlapping.
* https://design-system.service.gov.uk/components/inset-text/ There are dedicated HTML elements which semantically fulfill this div component's purpose (`blockquote`, `aside`...)
* File upload component: No value added to what browsers have out of the box ( https://design-system.service.gov.uk/components/file-upload/)
* Buttons and color: No matter if default (green), secondary (grey) or warning (red): the moment these buttons receive focus, they all get the same focus color yellow, thereby no longer communicating their intent visually.
* Accordions, they are just confusing: where does a accordion's content start and end? Put some borders around it. The over-the-top focus highlight adds to this confusion https://design-system.service.gov.uk/components/accordion/
* ... Which brings me to the last point: The screaming focus yellow highlight. This and other stuff in this design system is bleeding-edge accessibility conformity: crank accessibility to 150%, help some with it, but also leave others confused by it. Maybe think about `:focus-visible` instead of `:focus`. But hey, Chrome Lighthouse gives 100/100 ;-). To end on something positive, I checked with NVDA and keyboard input superficially (e.g. search box) and accessibility/ `aria-` markup looked fine.
Allow me some critique:
> HTML code is way too verbose and there is plenty of unnecessary nested div soups.
Can you prove you can obtain the very same result with less tags?
> Does not allow more than one skip link ( https://design-system.service.gov.uk/components/skip-link ), as they are visually overlapping.
Why would you have more than one?
> HTML code is way too verbose and there is plenty of unnecessary nested div soups.
Can you prove you can obtain the very same result with less tags?
> Does not allow more than one skip link ( https://design-system.service.gov.uk/components/skip-link ), as they are visually overlapping.
Why would you have more than one?
- div soup: e.g. https://design-system.service.gov.uk/components/cookie-banne... The code nests 7 levels deep (including the wrapping form element). Turn on DevTools and pull elements out of their containers and delete the now empty containers. You will see it effectively doesn't affect layout both in Desktop and small screen. And with the wrapping class `.govuk-cookie-banner` it's introduced anyways that everything inside it is part of the cookie banner component. No need for `.govuk-cookie-banner__heading`, just match `.govuk-cookie-banner h1`
- More than one skip link: If there are several often-used targets within a page, e.g. main content, search input, language select, etc. See the skip links on https://developer.mozilla.org/en-US/docs/Learn for an example.
- More than one skip link: If there are several often-used targets within a page, e.g. main content, search input, language select, etc. See the skip links on https://developer.mozilla.org/en-US/docs/Learn for an example.
- https://a11y-101.com/development/skip-link
- https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocksI'm not a UI designer but to me it looks a bit like a website designed in Microsoft Word. Just a datapoint.
Government websites are not supposed to look good or to be at the forefront of design. The percentage of people with disabilities is well within the double digits, and government websites are supposed to work for them as well.
What is important is accessibility, clear access to information, good UX.
What is important is accessibility, clear access to information, good UX.
I think gov.uk shows you can build websites that do look good, and are very usable by as many people as possible.
Think of it more as a standardised toolkit for making things that look and behave consistently, for a wide range of use cases and audiences.
I was only around for the first six months or so of this project, but I’ve taken so much of what I’ve learnt into my current design system, and I continue to reference GDS’s continuing work as the gold standard for researched user interface patterns.