alphagov / accessibility-community-notes-and-discussion Goto Github PK

WCAG states the following "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content."

However, I think we need to make it clear that many of the AAA success criteria are required as not following them will result in reduced usability and some people being excluded. For example, we definitely require content to be written as clearly and simply as possible and for headings to be used.

Which of the following can/should we require as part of the minimum standard?

• 1.4.6 Contrast (Enhanced) - The visual presentation of text and images of text has a contrast ratio of at least 7:1
• 1.4.9 Images of Text (No Exception) - Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed.
• 2.1.3 Keyboard (No Exception) - All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
• 2.2.3 No Timing - Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events.
• 2.2.4 Interruptions - Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency
• 2.2.5 Re-authenticating - When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating
• 2.3.2 Three Flashes - Web pages do not contain anything that flashes more than three times in any one second period
• 2.4.9 Link Purpose (Link Only) - A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.
• 2.4.10 Section Headings - Section headings are used to organize the content
• 3.1.3 Unusual Words - A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon
• 3.1.4 Abbreviations - A mechanism for identifying the expanded form or meaning of abbreviations is available
• 3.1.5 Reading Level
• 3.1.6 Pronunciation
• 3.2.5 Change on Request - Changes of context are initiated only by user request or a mechanism is available to turn off such changes
• 3.3.5 Help - Context-sensitive help is available
• 3.3.6 Error Prevention (All)

In Understanding WCAG 2.0 it says "Make it clear what language the content is written in, for example for screen readers". Suggest extending this slightly to "Make it clear what language the content is written in, for example so screen readers can choose the appropriate accent and pronunciation".

A "skip to content" link only needs to be provided if there are links that need to be bypassed. If there is a "skip to content" link it needs to work in all browsers (so requires adding tabindex="-1" for it to work in chrome and safari).

Is it worth calling out the using standard form controls with good form markup will mean that your forms are likely to just work in screen readers and speech recognition software. Building your own interface controls requires lots of testing to ensure that they work in all assistive technologies.

While writing a blog post on how to change colours on website, we removed my personal recommendation of in which tools to test in. Angus said it sounds too much like guidance. That made me wonder if we should add something like that into our guidance, e.g. into the "Requirement 2: AT compatibility" document?

The initial text was:

My (minimum) recommendation for testing:

• Firefox (dark and light) via browser settings
• Windows high contrast setting and Edge

It’s not worth testing (at least not continuously) in Mac inverted colours as that is failsafe and extremely unlikely to cause any issues. Chrome extensions are also unlikely to cause issues.

We need to decide what it is we want to create. Expectations are changing based on issues (especially #3, #4, #5, #6 and #7).

Is this a high-level intro or a thorough explanation, and of what (accessibility at Gov.UK, WCAG, both, neither)?

Where do we draw the line between reinventing the wheel and pointing people to existing descriptions, definitions and other supporting materials?

Are we trying to define a new government standard, change the existing one, or just help understand the current status quo?

Are we trying to explain how to solve problems (common ones or otherwise), or provide some insight into general areas for consideration?

In Understanding WCAG it says of Guideline 1.1:
"Provide a text alternative (‘alt text’) for non-textual content like images, audio and video, to describe the content or convey the same information"

Guideline 1.1 doesn't typically apply to audio or video (time-based media is listed as one of the exclusions). Suggest:
"Provide a text alternative (‘alt text’) for non-text content like images."

Dynamic information that is communicated visually (such as an error message or alert, that something is selected, or a progress indicator) also needs to be made available to a screen reader.

In Getting an audit it says:
"• the WCAG levels you want to be tested against - this is usually levels A and AA"

Suggest taking out "usually" from this sentence. Level AA is the expected standard, and in anything other than extremely rare circumstances, there is no value in auditing to only one of these levels at a time.

We should open this out to include the possibility that we may come up with a Government Accessibility Standard or similar. For now we might just need to say everything must meet a minimum of level AA.

We should include things which aren't services in this definition too.

In Getting an audit it says:
"• is accredited or verified for accessibility [QUESTION FOR LEONIE: who might they be accredited or verified by?]"
There is no accreditation or independent body that verifies the capabilities of an accessibility agency. It is a good idea to ask the prospective agency for client testimonials, in addition to the other things suggested in the remainder of this list.

In Understanding WCAG 2.0 it says "There are 3 levels to WCAG: easy (A), medium (AA) and hard (AAA)". The levels represent degrees of accessibility though, not difficulty. Level A represents a basic level of accessibility, Level AA represents an intermediate level, and Level AAA represents an advanced level (that is unlikely to be applicable across an entire site).

"You can also get general feedback from disabled users by getting experienced testers to do an expert review. The
Digital Accessibility Centre
can help find you a tester. [FACT CHECK QUESTION FOR LEONIE - HOW ELSE CAN USERS GET AN EXPERT REVIEW?]"

Most accessibility agencies can provide an expert review if asked. When I last looked into this, Nomensa, Abilitynet and DAC could all provide expert reviews by disabled and older people.

It might be worth looking into Access Works. It's a US based initiative that provides access to a global network of disabled people, able to assist with testing online services. I know the organisation behind the initiative, so could make enquiries about its suitability for Gov.UK?

Providing some information about what WCAG is will help people understand why we require people to follow it and how it will help them make a service more accessible.

• guidelines that specify how to make websites accessible, primarily for people with disabilities
• created by international accessibility experts at the W3C with input and feedback from people with disabilities
• considers the needs of people with disabilities and age related impairments with respect to the common barriers that they face when using a web site as well as the technologies that people use to overcome impairments and barriers (assistive technologies)
• considers people with:
  • visual impairments, including colour blindness, low vision and blindness
  • hearing impairments, including people who are non-signing and hard of hearing and people who are Deaf and use BSL
  • physical impairments such as having restricted upper body mobility and not being able to use a mouse or not having fine motor control
  • cognitive impairments such as dyslexia, learning difficulties and being on the autistic spectrum which means that understanding and navigating content may be difficult
• considers assistive technologies such as:
  • using a web browser to customise the layout of a website by specifying preferred font, font size, font colour and background colour
  • using a keyboard to navigate a website instead of a mouse
  • using software that converts text to audio (screen readers) so that content that is available visually is available through hearing
    using software that converts text to touch (electronic braille) so that content that is available visually is available through touch as braille
  • using software that makes content more legible by magnifying everything on screen and that can increase the colour contract (screen magnifiers)
  • using software that allows people to navigate a website with their voice and input content through dictation (speech recognition software).

People need to do more than 'Provide text alternatives for images' - they need to provide text alternatives that communicates the same information that is being being communicated visually by an image.

All interface controls need appropriate text - such as form controls and multimedia player buttons

All frames/iframes need appropriate titles

People also need to ensure that all information is still communicated visually when page colours are changed (for example by changing the browser settings or when using screen magnification software such as ZoomText)

We can improve these to match the language that is used in the service manual for roles in service delivery teams - and the roles that are expected to be in teams

• Product and service managers
• Delivery managers
• User researchers
• Content designers/managers
• Designers (service designers, interaction designer and visual designers)
• Developers
• Testers

Can we do more to explain what Perceivable means?
Would it be useful to convey some of the following in a more succinct way?

For content to be perceived by someone it needs to be available to at least one of the following senses: sight, hearing, touch.

For someone that has low vision this means they can see it - which requires the content to be large enough and the colour contrast to be high enough. As a baseline with want text to have a good colour contrast and for text to be a good size - so that as many people as possible can see it without having to adjust it. For people where this is not sufficient they need to be able to either customise the interface in the browser (change the font size and/or the colour) or by using software such as screen magnification. These will only work if a web content has been implemented in such a way that it is compatible with browser settings (and a user knows how to change the browser settings) and compatible with screen magnification software.

For someone that can't see this means that the content needs to be available to them as sound or touch. This is achieved by using software that converts text to sound ( a screen reader) and to touch (electronic braille). This will only work if the web content has been implemented in such a way this it is compatible with the assistive technology, for example all text is available as text in the HTML, that the text is in correct order in the HTML, and that correct HTML elements have been used to markup the content, and best practice has been followed to convey information about the layout of a page, content, forms and tabular information.

In Understanding WCAG it uses the word "subtitles". For accessibility purposes the correct word is "captions" - and almost all of the information found online about this topic will refer to them as such.

Note: internationally subtitles are provided for people who do not speak the language of the original content, captions are provided for people who do speak that language but are unable to hear it.

In Getting an audit it says:
"You don’t need to get your whole service audited. Choose some pages or steps that are typical for your service."

This may give the impression that picking a small number of pages is all that's required. It might be better to be clear that the sample needs to contain examples of *all page layouts, components and types of interaction. For example:
"You don’t need to get your whole service audited. Choose some pages or steps that between them include at least one example of each different kind of page and component your service uses."

I think 'Make sure the name, role and state of every feature can be identified' needs more explanation - won't make much sense to most people

Robust is about making sure that a website/service work in the technologies that people are using. Would be good to call out that this means that they need to work in screen readers, speech recognition software, screen magnification software and literacy software and to link to our assistive technology (AT) and Browser matrix (when we have it) and any guidance we have about AT testing. Should we also link to the the browser support guidelines in the service manual?

In Understanding WCAG it says of Guideline 1.2:
"a transcript for any video with sound, or an audio description of the video ("

In this instance the transcript is for the benefit of people unable to see the video, rather than those unable to hear it. Suggest:
a transcript containing visual descriptions , or an audio description of the video )

"Understands that for a website to be considered legally accessible it will need to meet WCAG 2.0 AA and have included people with disabilities in design and usability testing "

As far as I know the Equality Act doesn't specify any of this, and there is no definition of what is legally accessible, other than the reasonable adjustments test.

In Understanding WCAG it says:
"Make sure the purpose of a link is obvious from either the link text or the surrounding content ("

When you drill into the requirements for this, it says that the purpose of the link must be understandable from its link text, or from its surrounding content *if that relationship can be understood by screen readers and the like. The reality is that most of the time ATs can't determine that relationship, so we should simplify this to:
"•Make sure the purpose of a link is obvious from the link text, or from additional content associated with the link"

Not sure "themes" is the right word? Does "principles" not fit in because of reading age? Rules would be simpler but "WCAG 2.0 has four rules doesn't sound right".

In Getting an audit the words "small" and "full" are used to describe different audits. There is no concept of a "small" audit because the only thing that changes is the size of the sample to be tested. So whether the sample is 50 patterns from a library, 10 pages from a website, or 25 steps from a transactional service, the audit is always "full" because the sample is always tested against the complete set of WCAG SC.

Suggest using phrases like "pattern library audit", beta audit" etc. instead of these words.