Skip to content

Commit

Permalink
Accessibility roles #23 accessibility statement #28 and testing content
Browse files Browse the repository at this point in the history 
#27
  • Loading branch information
Andy Jones committed Jun 13, 2022
1 parent 2f367a2 commit d0cf2a3
Show file tree
Hide file tree
Showing 4 changed files with 169 additions and 59 deletions.
3 changes: 3 additions & 0 deletions source/accessibility/accessibility-audit.html.md.erb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,9 @@ Most tools will run in the browser or can be added as browser extentions to Edge
</tbody>
</table>

You can find out more about the responsibilities of [testing](/accessibility/roles.html#developers-and-testers) for accessibility and ensuring your [definition of done](/accessibility/roles.html#definition-of-done) covers accessibility.


### Internal audit

If you don't have people in your team who can do this, you can request an internal audit.
Expand Down
107 changes: 106 additions & 1 deletion source/accessibility/accessibility-statement.html.md.erb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,4 +6,109 @@ weight: 260
# Accessibility statement


THIS PAGE NEEDS WORK
All DfE digital services, website and any mobile apps must publish an accessibility statement. This has been a legal requirement since September 2018.

A link to the statement should be easy to find on the website and service homepage, or made available on every web page, for example, in the footer links.

For mobile applications, the statement should be available on the website of the public sector body that developed the app, or with other information available when downloading the app. The statement may also be made available from within the app.

## Required statement wording

<%= warning_text("The accessibility statement contains mandatory and legally required wording.")%>

Content in the square brackets should be replaced with your own wording appropriate for your wesbite or service.



> ### Accessibility Statement
>
> Department for Education is committed to making its [website(s)/mobile application(s), as appropriate] accessible, in accordance with the > > Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

> This accessibility statement applies to [insert scope of statement, e.g. website(s)/mobile application(s) to which the statement applies, > as appropriate].
>
> [For mobile applications, please include version information and date.]
>
> [For websites and services include the following section about adjusting content and presentation]
>
> We want as many people as possible to be able to use this website. For example, that means you should be able to:
>
> - change colours, contrast levels and fonts
> - zoom in up to 300% without the text spilling off the screen
> - navigate most of the website using just a keyboard
> - navigate most of the website using speech recognition software
> - listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)
>
> We’ve also made the website text as simple as possible to understand.
>
> AbilityNet (https://mcmw.abilitynet.org.uk/) has advice on making your device easier to use if you have a disability.
>
> ### Compliance status
>
> [Choose one of the options below, e.g. a, b or c and delete those not applicable.]
>
> [Select a, only if all requirements of the technical specification are fully met without exceptions.]
>
> a. [This] [These] [website(s)] [mobile application(s)] [is] [are] fully compliant with the Web Content Accessibility Guidelines version 2.1 AA standard.
>
> [Select b, if most requirements of the technical specification are met, but with some exceptions. This means not yet fully compliant and that the necessary measures are to be taken in order to reach full compliance.]
>
> b. [This] [These] [website(s)] [mobile application(s)] [is] [are] partially compliant with the Web Content Accessibility Guidelines version > 2.1 AA standard, due to [the non-compliance(s)] [and/or] [the exemptions] listed below.
>
> [Select c, if most requirements of the technical specification are not met]
>
> c. [This] [These] [website(s)] [mobile application(s)] [is] [are] not compliant with the Web Content Accessibility Guidelines version 2.1 AA standard. The [non-compliance(s)] [and/or] [the exemptions] are listed below.
>
> ### Non-accessible content
>
> [This section or individual headings within this section can be deleted if not applicable.]
>
> The content listed below is non-accessible for the following reason(s):
>
> a. non-compliance with the accessibility regulations
>
> [List the non-compliance(s) of the website(s)/mobile application(s), and/or, describe which section(s)/content/function(s) are not yet compliant].
>
> [Describe in non-technical terms, as far as possible, how the content is not accessible, including reference(s) to the applicable requirements in the relevant standards and/or technical specifications that are not met.]
>
> b. disproportionate burden
>
> [List non-accessible section(s)/content/function(s) for which the disproportionate burden exemption, within the meaning of the accessibility regulations is being temporarily invoked]
>
> c. the content is not within the scope of the accessibility regulations
>
> [List non-accessible section(s)/content/function(s) which is/are out of scope of the accessibility regulations].
>
> [Indicate accessible alternatives, where appropriate].
>
>
> ### Preparation of this accessibility statement
>
> This statement was prepared on [date].
>
> [Insert date of the first preparation, or a subsequent update, of the accessibility statement following an evaluation of the websites/mobile applications to which it applies. It is recommended that an evaluation is carried out and the statement updated following a substantial revision of the website/mobile application.]
>
> [Indicate the method used to prepare the statement. The method should be an actual evaluation of the website’s or mobile application’s compliance, such as a self-assessment done by the public sector body or an assessment carried out by a third party, for example a certification].
>
> [The statement was last reviewed on [insert date of latest review].

> [It is recommended that the claims made in the accessibility statement are reviewed as regards their accuracy on a regular basis, and at least once per year. If such a review has taken place without a full evaluation of the website/mobile app, whether or not such a review has led to any changes in the accessibility statement, please indicate the date of the last such review.]
>
> ### Feedback and contact information
>
> [Provide a description of, and a link to, the feedback mechanism to be used to notify the public sector body of any compliance failures and to request information and content excluded from the scope of the Directive].
>
> [Provide the contact information of the relevant entity(ies)/unit(s)/person(s) (as appropriate) responsible for accessibility and for processing requests sent through the feedback mechanism].
>
> ### Enforcement procedure
>
> The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’).
>
> If you’re not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).
>
> [Note: if your organisation is based in Northern Ireland, refer users who want to complain to the Equalities Commission for Northern Ireland (ECNI) instead of the EASS and EHRC.]
>
> [The statement should link to the website of EASS or ECNI]
>
> EASS - <%= external_link("https://www.equalityadvisoryservice.com/","https://www.equalityadvisoryservice.com/")%>
>
> ECNI - <%= external_link("https://www.equalityni.org/Home","https://www.equalityni.org/Home/")%>
117 changes: 59 additions & 58 deletions source/accessibility/roles.html.md.erb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ A service owner is accountable for the quality of their service. This includes a

## Delivery manager

A delivery manager is accountable for the delivery of complex products and services that are being delivered by multiple teams or have high technical or political risk
A delivery manager is accountable for the delivery of complex products and services that are being delivered by multiple teams or have high technical or political risk.

- remove blockers and manage risks, commercials, budgets and people in relation to accessibility
- balance objectives and can redeploy people and resources as priorities change, including people with accessibility skills and experience
Expand All @@ -36,18 +36,70 @@ A delivery manager is accountable for the delivery of complex products and servi

## Product manager

Accessibility shouldn't be a blocker in the delivery process. A product manager should be ensuring that the prodct you are building meets the required accessibility standards. This includes your Minimum Viable Product (MVP). You can’t go live and implement accessibility at a later date.

- when planning, include time for acessibility testing time (automated and manual)
- update the accessibility statement where necessary as part of releases

Product managers need to understand the risks of building a service which is not accessible.

If the service is not accessible, then you won’t be able to pass a Beta assessment. If you put a service live and it is non-compliant, the service can be reported to the <%= external_link("https://equalityhumanrights.com/en","Equality and Human Rights Commission")%>.

As the enforcement body the Equality and Human Rights commission has the power to issue enforcement notices, do investigations and even take court action against the department.

## User researcher

User researchers will help the team to understand the needs of the people who use the service, including those users who might have impairments and use assistive technologies.

Even before you have identified users in your own service, you can familiarise yourself with the <%= external_link("https://www.gov.uk/government/publications/understanding-disabilities-and-impairments-user-profiles", "GOV.UK user profiles")%> and how different impairments might affect people using the service.

Researchers should:

- test a service with a range of people with different abilities
- share insights with the rest of the team about how users of assisitive technology use the service

<%= signpost_link("https://drive.google.com/drive/u/0/folders/1N-kos9wCVFhDZDbasJc6wPcM2YsK8pp5", "More guidance for user researchers in DfE", true)%>

## Design

Accessibility guidelines which apply to people working in the design of user interfaces and user interactions with a service.
Accessibility guidelines which apply to people working in the design of content, user interfaces and interactions in services and websites.

Working to defined standards ensure services the Department for Education (DfE) create are inclusive and accessible and can be used by all people.

<%= signpost_link("https://design-in-dfe.education.gov.uk/", "Accessibility standards breakdown in the Design in DfE service", true)%>
This includes removing risk by designing how things should work, this can be achieved by:

- working with other designers, researchers and developers to build and test prototypes
- following inclusive design principles
- ensuring you meet component design criteria
- contributing to the GOV.UK Design System backlog
- sharing your work with other designers across DfE
- taking part in design crits, reviews and assessments to assure your designs are meeting these standards

<%= signpost_link("https://design-in-dfe.education.gov.uk/", "Full guidance, information and standards in the Design in DfE manual", true)%>



## Developers and testers

Developers need to work closely with interaction designers and content designers to make sure things like hover states, error messages and hidden text are considered.

Testers should be ensuring that accessibility testing is included to find obvious problems.

### Definition of done

We can’t deploy code which is not accessible, otherwise we are breaking the law. So if it’s not accessible it’s not done. As part of your definition of done, the service should be checked for accessibility using both automated and manual tests.

An example of accessibility considerations in a definition of done:

- automated accessibility tests passing in the acceptance tests
- manual accessibility tests passed using Accessibility Insights
- manually checked usability using a screen reader
- manually checked usability using a screen magnifier
- manually checked usability using speech recognition
- accessibility statement updated

<%= signpost_link("https://technical-guidance.education.gov.uk/", "Additional guidance is avialble in the DfE Technical manual", true)%>

## Architects

Architects are responsible for ensuring the components of the technical design for a service are able to meet accessibility standards.
Expand All @@ -56,61 +108,10 @@ That could be through technical designs they create or ensuring appropriate non-

They also have a role in assuring a service is meeting accessibility standards, through internal technical assurance, for example, peer reviews, for a service assessment or managed service delivery reviews.

<%= signpost_link("https://dfe-digital.github.io/architecture/#dfe-architecture", "Additional guidance is avialble in the DfE Architecture manual", true)%>


## Performance analyst

Performance analysts considerations will be around presenting statistical data so that they don’t exclude anybody that might not be able to perceive complex charts or tables of data.

<div class="cards">
<ul>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
<li class="card">
<div class="text">
<h2><a href="#card-link">A card</a></h2>
<p>Commodo ut laborum fugiat aliqua eiusmod voluptate pariatur.</p>
</div>
</li>
</ul>
</div>

<script>
const cards = document.querySelectorAll('.card');
Array.prototype.forEach.call(cards, card => {
let down, up, link = card.querySelector('h2 a');
card.style.cursor = 'pointer';
card.onmousedown = () => down = +new Date();
card.onmouseup = () => {
up = +new Date();
if ((up - down) < 200) {
link.click();
}
}
});
</script>
1 change: 1 addition & 0 deletions source/stylesheets/screen.css.scss
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1212,3 +1212,4 @@ ol.dfe-standards-list {
font-size: 1rem;
}

.technical-documentation blockquote {background: #f3f2f1; margin: 20px 0px 0px 0px; padding: 10px 25px }

0 comments on commit d0cf2a3

Please sign in to comment.