Get in touch
-If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.
+If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.
Get in touch
-If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.
+If you’ve got a question or suggestion share it on the Home Office DDaT Slack channel #ask-accessibility or email access@digital.homeoffice.gov.uk.
Do not:
@@ -76,7 +76,7 @@ const Page: FCOther considerations
If your form control is more complex than a text field or dropdown, consider giving users help with how to use the control via hint text. You should also offer an alternative, for example allowing users to type in a date field as well as having a date picker.
-Using keyboard, switch or other input devices can be tiring for people with motor impairments so make sure users don’t have to use Tab more than they need to. Things like typeahead fields, the autocomplete attribute and considering field number and order can help make your form easier to use.
+Using keyboard, switch or other input devices can be tiring for people with motor impairments so make sure users don’t have to use Tab more than they need to. Things like typeahead fields, the autocomplete attribute and considering field number and order can help make your form easier to use.
Get in touch
diff --git a/apps/docs/src/common/pages/accessibility/headings.tsx b/apps/docs/src/common/pages/accessibility/headings.tsx index ddb45943..5807a0ff 100644 --- a/apps/docs/src/common/pages/accessibility/headings.tsx +++ b/apps/docs/src/common/pages/accessibility/headings.tsx @@ -119,7 +119,7 @@ Headings are defined by using<h> tags which come in the form
Similarly, if part of your content works as a heading (for example, to head up content blocks in the footer, or in a sidebar list of related links) then you must use the correct HTML code as well as any visual styling. If you don’t, a screen reader will not recognise this as a heading and the user may miss it.
-Where sections are broken up with visual design alone, it may be worth adding a screen reader-only heading to help non-visual users navigate these parts of the page. You can do this with a ‘visually hidden’ style in CSS.
+Where sections are broken up with visual design alone, it may be worth adding a screen reader-only heading to help non-visual users navigate these parts of the page. You can do this with a ‘visually hidden’ style in CSS.
Get in touch
diff --git a/apps/docs/src/common/pages/accessibility/inclusive-language.tsx b/apps/docs/src/common/pages/accessibility/inclusive-language.tsx index 2768b487..bf245ee3 100644 --- a/apps/docs/src/common/pages/accessibility/inclusive-language.tsx +++ b/apps/docs/src/common/pages/accessibility/inclusive-language.tsx @@ -46,7 +46,7 @@ const Page: FCDisability
-As well as following our accessible design principles, you should consider how your language is inclusive to people who face different barriers to accessing services.
+As well as following our accessible design principles, you should consider how your language is inclusive to people who face different barriers to accessing services.
Do:
- clearly signpost users to alternative methods of accessing the service and get support if needed diff --git a/apps/docs/src/common/pages/accessibility/keyboard.tsx b/apps/docs/src/common/pages/accessibility/keyboard.tsx index 34ae509b..a8aa94c9 100644 --- a/apps/docs/src/common/pages/accessibility/keyboard.tsx +++ b/apps/docs/src/common/pages/accessibility/keyboard.tsx @@ -50,7 +50,7 @@ const Page: FC
- trap keyboard users in content that stops them moving around the rest of the page
- use single character key shortcuts
See more in WCAG basics easy keyboard checks.
+See more in WCAG basics easy keyboard checks.
| - 1.1.1 - Non Text content + 1.1.1 - Non Text content |
All non-text content like images, charts, icons and infographics, must have an appropriate text equivalent. This ensures that information conveyed by non-text content is available to people who cannot see it, like screen reader users. @@ -75,7 +75,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Audio and video content has appropriate alternatives to ensure that everyone has a comparable experience when interacting with this content. This may include transcripts, captions and audio description depending on the type of audio or video content. @@ -83,7 +83,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
When information is visually presented as a table, this structure must be conveyed appropriately to assistive technologies. This ensure that tables are available to screen reader, screen magnification and speech recognition tool users. @@ -92,7 +92,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
When presenting lists of information, you must communicate this list in a way that assistive technology users can understand. @@ -101,7 +101,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Where visual headings are used to communicate the structure of a page, they must also be communicated in a way that supports assistive technology users to access this structure. @@ -110,7 +110,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
All form fields have an associated visible label. Where this isn’t possible a non-visible label must be present. @@ -120,7 +120,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Content sections within a page should have an appropriate HTML5 section element or ARIA landmark role defined. @@ -128,7 +128,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
When the order of content is important, the content order must be preserved no matter how it is presented to the user. @@ -137,7 +137,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Instructions must not depend on sensory characteristics like shape, size, colour, or location. This ensures that instructions can be understood by users who are unable to see or recognise information communicated using sensory characteristics. @@ -145,7 +145,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
A page view must not be locked to either horizontal or vertical views only, unless this is essential. @@ -154,7 +154,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
In an input field, the purpose of each input field that collects information about the user can be understood by assistive technologies and browsers by using autocomplete. @@ -162,7 +162,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Information conveyed with colour must also be identifiable from context, labelling, or alternative forms. @@ -170,7 +170,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Audio/video must not play automatically unless the user is pre-warned and can control the audio. @@ -178,7 +178,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
There should be enough difference (contrast) between a background and the foreground content so that user can easily differentiate the two. @@ -186,7 +186,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Users should be able to resize text up to 200% without any problems with the presentation and structure of the page (for example truncated text, overlaps or missing items). @@ -194,7 +194,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Meaningful text must not be presented as part of an image because it cannot be resized, it deteriorates in quality when magnified and is not customisable by the end user. @@ -203,7 +203,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Users should be able to magnify the page up to 400% and content should reflow - move into one column - and not add horizontal scroll bars. @@ -212,7 +212,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Interactive controls, keyboard focus, icons and content required for understanding e.g. charts and infographics must have enough contrast (at least 3:1) with adjacent colours. @@ -220,7 +220,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
For regular HTML page content, no loss of content or functionality happens when a user changes line height, letter or word spacing. @@ -228,7 +228,7 @@ const Page: FC | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| - + |
Ensuring that extra content eg tooltips:
@@ -257,7 +257,7 @@ const Page: FC It must be possible for someone using a keyboard to complete all tasks in a service. No item traps the keyboard focus; upon reaching any item on the page, it is possible to move to the item that precedes or follows it using the keyboard. If single character key shortcuts have been set up within a page, the user can switch them off or remap them. When a time limit, like a session timeout, is set ensure a user is informed,especially if this may result in a loss of data. It must be possible for the user to define the length of the timeout (e.g. in settings), turn it off, delay it, or extend the length of time. Avoid moving or animated content on pages. A page must not contain content that flashes more than three times a second. When there is repeated content (like a header) at the top of the page, there must be a way for keyboard users to move focus directly to the start of the main content area of the page. Each page must have a unique title that indicates its topic or purpose. It must be possible to navigate through content in a way that makes sense. Link text should make it clear what the link is i.e. where the links goes. Links should make sense out of context e.g. when using a links list. Unless the service is a series of steps, there must be different ways for people to locate and navigate content. Headings must indicate the topic or purpose of the content in that section of the page, and labels must indicate the purpose of the field they relate to. It must be easy to tell which element has keyboard focus. Any functionality which requires a multipoint or path based gestures has an alternative single pointer, non path-based gesture. Any script triggering must be done on the ‘up’ event – not the ‘down’ event. For user interface components with labels that include text or images of text, the Accessible name contains the text that is presented visually. Any functionality that is initiated by tilting or shaking (etc) a device, must be able to be intiated by a button, or other control. The written language of the page must be identified in the code of the web page. When a keyboard user focuses on a control it must not cause a change of context, such as loading a new page/tab. Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. When ways to navigate content are repeated on multiple pages, they must be presented in a consistent manner. When features with the same functionality are used in multiple places, they must be identified in a consistent way. When an error occurs the user is informed what caused the error, and the error is described in text in an accessible way. When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. Password fields should allow a user to view and check the entry. When data must be entered in a specific format or in a particular way, clear instructions must be associated with the form field. Password fields should allow a user to view and check the entry. All transactions should be reversible, or confirmation must be required before submission. The code of the page must not cause browser or assistive technology conflicts. This ensures that content and functionality is presented in a way that works reliably across all supported browsers and assistive technologies. All interactive components must have an accessible name and role, and the state of the component must be communicated to assistive technologies. There are different situations where a page needs to dynamically display a status message. These messages need to be conveyed to assistive technology users, even when they don’t receive focus. Where possible, you should avoid disturbing the user’s place in a page. When doing user research, make sure to include users with disabilities (at least 1 out of every 5 participants). When conducting user research you must include users with disabilities. Text alternative for non-text content, captions and other alternatives for multimedia should be provided, and content should be adaptable by the user to fit their requirements. 1.2.x - Alternatives for audio and video 1.2.x - Alternatives for audio and video Check if there are any open discussions about your suggestion on the design system GitHub. Check if there are any open discussions about your suggestion on the design system GitHub. If there is not a discussion, start a new discussion on GitHub. Select ‘ideas’ from the ‘select category’ list when starting to create the discussion. For help, use our GitHub guide or ask the working group. If there is not a discussion, start a new discussion on GitHub. Select ‘ideas’ from the ‘select category’ list when starting to create the discussion. For help, use our GitHub guide or ask the working group. When discussing a proposal for a new component, try to explain why it should be included in our design system. If you can, include screenshots and research findings. Let the user-centred design and accessibility community know that you have posted a new discussion and ask their comments. Consider giving your discussion topic a deadline of a few weeks. Use the comments to make a suggestion for an improvement or a new entry. Contact design@digital.homeoffice.gov.uk if you'd like feedback on your discussion or for the design system working group to review it. Contact design@digital.homeoffice.gov.uk if you'd like feedback on your discussion or for the design system working group to review it. The design system working group regularly assess discussions using the GOV.UK design system contribute criteria. The design system working group regularly assess discussions using the GOV.UK design system contribute criteria. If the pattern or component is ready to be published, the working group will then raise an issue and progress this work further. The working group will share updates in the user-centred design community email about proposal decisions and changes to the Home Office design system. The working group will also: If you have a question or idea, you can contact the working group: Our GitHub repository discussions is where our designs are discussed and problems explored. Our GitHub repository discussions is where our designs are discussed and problems explored. Create a GitHub account with any email address, including your Home Office email addresses. Create a GitHub account with any email address, including your Home Office email addresses. If there's an existing discussion, you can: Your new discussion can be as simple as a thought you've had, or more well-formed research findings. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. More research is needed. If your service uses this
- pattern, get in touch to share your user research findings. Consider alternative ways a user can submit a declaration offline. If your service uses this pattern, let us know of any insights you have
on accessibility considerations. If you've got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. Multiple Home Office services use search. If you have evidence this also works for your users, you can contribute to our backlog Multiple Home Office services use search. If you have evidence this also works for your users, you can contribute to our backlog Tabbing in a logical way to the interactive elements, being able to see the focus, and being able to interact with it. If not using native HTML elements and creating something custom refer to https://www.w3.org/TR/wai-aria-practices/wai-aria-practices for expected interaction. Tabbing in a logical way to the interactive elements, being able to see the focus, and being able to interact with it. If not using native HTML elements and creating something custom refer to https://www.w3.org/TR/wai-aria-practices/wai-aria-practices for expected interaction. You should make sure If you've got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. Adding content to a new page instead of showing it in a modal should be the default
approach. Modals can be useful when you need to draw a user's attention to something, for example
- timeout warnings. Please discuss with the wider community or email design@digital.homeoffice.gov.uk before
+ timeout warnings. Please discuss with the wider community or email design@digital.homeoffice.gov.uk before
using this pattern. Read our accessibility guidance on timeouts. Read our accessibility guidance on timeouts. If you’ve got a question or suggestion share it on the Slack channel
#ho-design-system, on GitHub or
- email design@digital.homeoffice.gov.uk. Always use the Home Office colour palette when you are designing and building internal services and products. For public facing and transactional sites use the GOV.UK colour palette. Ask design@digital.homeoffice.gov.uk if you have any questions. Ask design@digital.homeoffice.gov.uk if you have any questions. Images must be relevant to the content, help users understand what they need to do and follow our guidance on the use of alternative text. Please contact design@digital.homeoffice.gov.uk for advice on image use and for original source files. Please contact design@digital.homeoffice.gov.uk for advice on image use and for original source files. Illustrations must have a consistent style to create trust. This includes print products as well. If you’ve got a question or suggestion share it on the Slack channel #ho-design-system, on GitHub or email design@digital.homeoffice.gov.uk. If you’ve got a question or suggestion share it on the Slack channel #ho-design-system, on GitHub or email design@digital.homeoffice.gov.uk. These cookies are not used to identify you personally. You’ll see a message on the site before we store a cookie on your computer. Find out how to manage cookies. Find out how to manage cookies. You will see a message about cookies when you first visit the Home Office Design System. We’ll store a cookie so that your computer knows you’ve seen it and knows not to show it again. If you have a question or need support you can: |