Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write accessibility acceptance criteria blog post #19

Closed
wants to merge 2 commits into from
Closed

Write accessibility acceptance criteria blog post #19

wants to merge 2 commits into from

Conversation

@fofr fofr force-pushed the aac branch from a957f84 to 4d4dc62 Aug 17, 2017
date: 2017-07-29
---

Accessibility acceptance criteria are a list of criteria that a user interface must meet to be considered accessible. They define what makes the building blocks of a user interface accessible and give teams criteria to test against. They a place to record accessibility decisions.

This comment has been minimized.

@vanitabarrett

vanitabarrett Aug 17, 2017

Typo: 'They a place to record'

date: 2017-07-29
---

Accessibility acceptance criteria are a list of criteria that a user interface must meet to be considered accessible. They define what makes the building blocks of a user interface accessible and give teams criteria to test against. They a place to record accessibility decisions.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

"They (are?) a place to record..."


> Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. [...] The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.
By defining accessibility acceptance criteria upfront we are forced to think about accessibility from the start. It helps us to [consider the range of users](https://accessibility.blog.gov.uk/2016/05/16/consider-the-range-of-people-that-will-use-your-product-or-service/). The criteria become a starting point for building accessible things.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

Suggest 'from the beginning' rather than 'from the start' as that is already used to end the sentence above.

This comment has been minimized.

@fofr

fofr Aug 17, 2017
Author Owner

That alliteration was intentional.

While all text must have a sufficient contrast ratio, given this component’s use of colour it has an increased risk of introducing a barrier.

Note also that WCAG AA defines different ratios for large and small text, we’ve found that the definition of large and small can be misinterpreted. Using one contrast ratio for all text eliminates any chance of mistake.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

Not sure about this sentence structure. How about "While WCAG AA defines different ratios..."

While all text must have a sufficient contrast ratio, given this component’s use of colour it has an increased risk of introducing a barrier.

Note also that WCAG AA defines different ratios for large and small text, we’ve found that the definition of large and small can be misinterpreted. Using one contrast ratio for all text eliminates any chance of mistake.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

Should this be "eliminates any chance of (a) mistake"?

This comment has been minimized.

@fofr

fofr Aug 17, 2017
Author Owner

Maybe, "prevents mistakes"


Criteria are useful if they are specific and testable.

When we began writing accessibility acceptance criteria for components we had difficulty knowing what to include. Consider a component that contains links – do the criteria need to list everything that make a link accessible? How much of this becomes a reproduction of existing guidelines?

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

...everything that makes a link accessible?


Guidance is for users, accessibility acceptance criteria are for maintainers.

Not everything is under your control. For instance, some of our components may become inaccessible if they’re passed certain parameters. Consider a contrived example of the translation component being passed data that says a link is in English but on inspection actually reads in Arabic.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

Are you going to add some kind of conclusion after this?

This comment has been minimized.

@fofr

fofr Aug 17, 2017
Author Owner

Yes, I want to. Any suggestions?

This comment has been minimized.

@andysellick

andysellick Aug 18, 2017

We could do a general 'accessibility is good and this helps us do it' kind of closer, but it would be better to speak from our experience - like if we were able to say specifically how doing all this helped us (e.g. we found and fixed some accessibility issues). I'm not sure we're there yet, though.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

I'm not sure what this paragraph is trying to say.

date: 2017-07-29
---

Accessibility acceptance criteria are a list of criteria that a user interface must meet to be considered accessible. They define what makes the building blocks of a user interface accessible and give teams criteria to test against. They a place to record accessibility decisions.

This comment has been minimized.

@andysellick

andysellick Aug 17, 2017

The words 'accessibility', 'accessible' and 'criteria' happen a lot in this paragraph. How about...

'Accessibility Acceptance Criteria are standards that a user interface must meet to be considered usable by a wide range of people with differing needs who use a range of methods to interact with that interface. They define what makes the building blocks of that user interface accessible and provide a basis for accessibility testing. They are also a place to record the research and decisions that led to those criteria, so that future work can be informed by it.'

This comment has been minimized.

@fofr

fofr Aug 17, 2017
Author Owner

Standards is a bit of an overloaded word. Not sure if we need to delve into the larger meaning of accessibility.

This comment has been minimized.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

I'm not convinced they are a place to record decisions.

Copy link

@edwardhorsford edwardhorsford left a comment

Added a bunch of comments. Good first draft!

date: 2017-07-29
---

Accessibility acceptance criteria are a list of criteria that a user interface must meet to be considered accessible. They define what makes the building blocks of a user interface accessible and give teams criteria to test against. They a place to record accessibility decisions.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

I'm not convinced they are a place to record decisions.


> Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. [...] The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.
By defining accessibility acceptance criteria upfront we are forced to think about accessibility from the start. It helps us to [consider the range of users](https://accessibility.blog.gov.uk/2016/05/16/consider-the-range-of-people-that-will-use-your-product-or-service/). The criteria become a starting point for building accessible things.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

"by defining upfront" and whilst developing. Acceptance criteria might change as you learn more - I wouldn't want to imply they're static.

This comment has been minimized.

@fofr

fofr Sep 5, 2017
Author Owner

This paragraph is mostly about "accessibility from the start", I've changed to: "By drafting accessibility acceptance criteria upfront", draft should imply that they can change.

While all text must have a sufficient contrast ratio, given this component’s use of colour it has an increased risk of introducing a barrier.

Note also that WCAG AA defines different ratios for large and small text, we’ve found that the definition of large and small can be misinterpreted. Using one contrast ratio for all text eliminates any chance of mistake.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

is this paragraph relevant?

This comment has been minimized.

@fofr

fofr Aug 23, 2017
Author Owner

Probably not. It's in anticipation of "Actually, large text only needs a contrast ratio of X"


When building user interfaces we do our best to ensure they are accessible. But without a definition of what made it accessible it’s hard to iterate on and too easy to introduce accessibility regressions. Even when we know it’s been built well, and that effort went into making it accessible – how do we make changes without breaking accessibility? What stops our new definition of accessibility from being incomplete or different to the original definition?

Making something accessible can be nuanced and complex and [not all accessibility testing can be automated](https://blog.vararu.org/accessibility-testing-tools-are-lying-to-you/). There are always manual steps needed to test features in the way they impact users.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

The accessibility team has various blog posts on our research in to automated tools.


### Iterate criteria

As something is built and tested, continue to refine your criteria as you find missing needs. When accessibility bugs are found – a browser bug, a screen reader quirk, new technology misbehaving, add further criteria and treat them like a failing unit test.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

I think this is the wrong way around. If a bug is found in AT that causes a barrier and it's not failing the criteria, then there's a gap in the criteria. However we don't want criteria for each bug - we want criteria that describe the component.


Guidance is for users, accessibility acceptance criteria are for maintainers.

Not everything is under your control. For instance, some of our components may become inaccessible if they’re passed certain parameters. Consider a contrived example of the translation component being passed data that says a link is in English but on inspection actually reads in Arabic.

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

I'm not sure what this paragraph is trying to say.


For many patterns the hard work of defining what accessible means has been documented in guidelines like WCAG. Do the hard work to extract rules specific to what you’re building and link back to the guidelines to give context. Consider which rules are most easily broken and give them prominence.

### Don't be too generic

This comment has been minimized.

@edwardhorsford

edwardhorsford Aug 23, 2017

Needs an opposite section / something about specifying the intent rather than the exact implementation.

Rough draft, probably too lengthy:

Don't be too specific

Accessibility criteria should define what needs a component needs to meet / the intent / information that needs to be conveyed, but should avoid specifying the exact outcome. The criteria should allow room for designers and developers to interpret the criteria and make improvements over time. Ideally if technology or design changes, the majority of the criteria should still apply.

Overly specific criteria:

  • A modal dialog must have a button in the top right corner that's labeled 'close' and closes the modal.

Criteria that specify the intent:

  • The modal dialog must be closable.
  • There must be a clear way to close the modal dialog.

This avoids specifying the exact text or interaction, and allows the designer freedom to test different designs. For each criteria, ask yourself if an alternate design or implementation do something different and still be accessible. If so, the acceptance criteria is probably too specific. In the above example, there are several design solutions for closing a modal that may be work equally well. It's important that users can close it easily, not that the text be precisely 'close'. It may be that the final finished design has a 'close' button - but framing the criteria around intent means that changing the text needs only satisfy the criteria that the user be clear on how to close it.

This comment has been minimized.

@fofr

fofr Aug 23, 2017
Author Owner

Excellent point. Will work with your draft.

@fofr
Copy link
Owner Author

@fofr fofr commented Sep 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.