Outcome Formats

[rachaelbradley]

At the 6 February meeting, we started the discussion of outcome formats (ways to write outcomes), as well as what content is normative. We would like to continue that discussion at this week's meeting. The list of possible ways (formats) to write outcomes is in the comments. You may need to Show Previous Replies to view them.

Our working document testing out the options may also be useful reading.

Please indicate which formats you support and which you have concerns about. This is a discussion on the way to write, not on the outcomes themselves. Comments about the outcomes themselves will be delete.

Instructions:

• Please put a thumbs up on all formats you support.
• Please put a thumbs own on all formats you have concerns about.
• Do not vote or use the eyes for formats you do not have an opinion on
• Please reply directly to the comment with the format you want to comment on. In general, DO NOT comment directly on this post. This keeps the threading clean.
• If you would like to suggest an additional format, reply to the main post with that format and examples. Use the other format comments as a template.

Summary from 13 February - Before AG Meeting

[rachaelbradley]

User statement examples

• Users with limited cognition or memory are able to complete processes, including login and authentication, without remembering a password, solving a puzzle or calculation, or passing another cognitive test.
• Users with visual, fine motor and cognitive disabilities have a way to complete a task before timeout.
• Users without vision are provided with non-visual alternatives that serve the same purpose and present the same information as images.

[alastc]

(Chair hat off) If we go down the route of defining an outcome, i.e. the desirable state when the product is accessible, I think this is the best way of achieving that.

We have over 200 outcomes that have come out of the process to date, they cover far more than WCAG 2.x. (Not that I expect nearly that many to be included at publication, due to overlap / research needed / other reasons.)

In going through those, I haven't found a lot of overlap in the next layer down, i.e. the method(s) you would use to achieve the outcome.

Where user-needs have been combined in WCAG 2, there is almost always one "primary" use-case. Where there are multiple (e.g. headings for both AT navigation and visually breaking up content for cognitive needs) I think they are better separated. The way you'd approach headings for AT usage can be quite different from just breaking up large chunks of text content, and we should be able to scope them differently.

[GreggVan]

+1 to the first part of @alastc comment.
but the last paragraph I'm not quite sure what it is saying. it talks about primary use-cases and separating. Which makes me nervous that we might be talking about assigning provisions being of primary benefit to some group -- or separating things by user group.

A large majority of the provisions benefit multiple groups. Tagging them and explaining how each provision helps different groups is great. Too many times a provision is attributed to one disability when it benefits many. And when we tag and explain (highly important to do) the groups should be in alphabetical order (not picking who benefits most under each and putting them first). For one that is subjective. Secondly what is more important to how many etc. Not any reason to go down those rabbit holes.

Grouping by Disability or even need (which will map back to disability) may not be the intent - but good to keep above in mind as we go forward.

[alastc]

Hi @GreggVan, if you look at the examples they are things like "Users with limited cognition or memory are able to...".

Putting aside the "Users need to be able to..." alternative, this approach is focused on saying "Users with disability X need to be able to do Y". So it is inherently focusing by disability, although if there is clearly more than one, that can be included as well.

A large majority of the provisions benefit multiple groups.

I agree to some extent, BUT, I think there is usually one primary group that is in mind for each SC. That others benefit is great, and we can track that behind the scenes. The advantage of this approach is that a primary use-case makes it more understandable for people less familiar with the guidelines.

Also, where things have been combined it can cause issues (the last paragraph of my last comment). One of the outcomes is currently "Sections of content have clear visual and programmatic labeled". However, the way you want to visually break-up content with headings can be different from making sure headings are programmatically available. The scoping, level, and methods should be different.

[GreggVan]

boy I don't think I ever said this before -- but I strongly disagree that we should attribute any provision to be PRIMARILY for one disability and to track or acknowledge the benefits to other disabilities in the background.

I think this would be a terrible mistake and to the extent people have done it in the past -- it has lead to provision counting and a misbelief in the number of provisions that were included to help different disabilities.

We should not ever group or attribute provisions to a disability - but should describe the provision - and then list all the different disabilities and conditions that it helps address. And I would not even order them by which ones are helped most. That again is subjective and is not what the world looks like if you have disability. Best

[LJWatson]

I think this approach has advantages, for example:

1. Technology changes rapidly, human needs not so much, so this approach would likely increase the longevity of 3.0
2. The format is close enough to the standard Connextra user story format to make it familiar to many/most production teams, reducing the on-ramp for teams using 3.0

The bit that doesn't feel quite right to me is the use of "disability" and/or "disabilities" in the example statements. I think it adds a layer of abstraction that makes it harder to understand why this thing is important. It also risks dehumanizing the "user" in the user statement I think. I don't regard myself as a "user without vision", I'm a "person who cannot see", and framing a user statement in simpler terms like this makes it easier to understand why I need there to be "alternatives that serve the same purpose and present the same information as images".

This might also go some way to addressing @GreggVan's concern in #49 (reply in thread). To continue the example, it doesn't matter if you cannot see because you're blind, because you have a Retinal Migraine, because you can see perfectly well unless you're using the web where there are too many moving and blinking parts for you to be able to concentrate so you listen to content instead, or because you got something in your eye - the user need is the same - we need the same information to be provided in a different form.

[rachaelbradley]

Needs statement examples

• I need to have adequate time to complete a task before timeout.
• I need to complete processes, including login and authentication, without remembering a password, solving a puzzle or calculation, or passing another cognitive test.
• I need to be able to customize content
• When text is used in an image, I need to know what the text says and whether the styling contributes to the meaning.

[mraccess77]

I believe this method has the same challenges as the user statements. While the needs and user statements are essential - I believe putting them as the outcomes would create hundreds of provisions that would be complex to dig through to understand the outcomes and what needs to be done. I believe it could be better to map these needs to outcomes as outcomes will be shared but different user needs.

[GreggVan]

Concur with Jonathan, we did a user needs document for ICT access and it goes on for pages and pages of small print. It is now an ISO technical report.

A better way is to GATHER NEEDS and use them as part of our process of developing the provisions - and then cite which needs particular provisions are helping to meet (though I think it should be in a linked informative document -- as per comments below)

[alastc]

(Chair hat off) I find the "I need to..." confusing, as even if you have a disability only a sub-set of the whole might be "I".

[rachaelbradley]

Requirement statement examples

• Completing a process shall not require remembering a password, solving a puzzle or calculation, or passing another cognitive test.
• For each timeout at least one of the following shall exist:
  -- a mechanism to disable or extend the timeout
  -- an alternative workflow to perform the same function with no timeout
  -- a mechanism to save progress before the timeout

[GreggVan]

@alastc
Absolutely agree on the tension between plain language and testable. Boy howdy do I know that. Fully half of the time in W2 was spent on that and we created several task forces over the years to bring in Plain language people to see what we could do better. And you can still see that, other than making very very long and complicated ones - they all ended up making some improvements but not figuring out how to do both.

But there is no option that requirements need to be clear and testable. So suggest that 1) we use plain language or needs 2) make requirements as plain language as we can -- but no more so [following Einstein who said -- 'everything should be as simple as possible - but no more so'] and 3) we can include plain language preludes or 'understanding' text.

[bruce-usab]

I was surprised how much I disliked the use of shall. Active voice reads better.

• Completing a process does not require remembering a password, solving a puzzle or calculation, or passing another cognitive test.
• For each timeout, at least one of the following exists...

[GreggVan]

@bruce-usab
Interesting but I have a question

• Completing a process does not require remembering ... appears to be active voice
• For each timeout, at least one of the following exists... appears to be passive voice

were you contrasting these (in which case - how would you make the second one active)
or did you just mean - you like both of these better than the "imperative" type of sentence (that has "shall")

I agree that I like the outcome oriented (both of the above) better than the imperative SHALL versions

I also think the outcome oriented "this must be true" is more future proof and allows the condition to occur in different ways including some that may be true by default in the future via the browser.

[bruce-usab]

@GreggVan -- I just meant that I like both of these better than the imperative type of sentence.

[patrickhlauke]

@bruce-usab "I was surprised how much I disliked the use of shall"

hard agree. makes it sound like some new testament commandments

[rachaelbradley]

Question Statement Examples

• Is the purpose and content of images understandable when the image is not visible?
• Is it possible to complete all steps in a process without remembering a password, solving a puzzle or calculation, or passing another cognitive test?
• Are users without vision able to determine whether an image is decorative or informative?
• Is there a mechanism to save task progress before the timeout?

[pbossley]

My opinion, using the question format leaves a lot of wiggle room for people to rationalize answers.

[alastc]

(Chair hat off) This feels like a variation on the requirement approach, just phrased as a question. Although there are variations with "Are users ... able to", I don't find it helps clarity to have it phrased as a question.

[GreggVan]

+1 to alastc
I thought phrasing it as a question was an attempt to see which form of language was the best for the standard. Which was good to see. But I agree that this does not look like a good format for the
I think that form (a question) might be more useful for teaching or something than for a standard. Standards are things you comply with - so provisions should be statements of fact/status -- or they are imperatives (SHALL) -- and I THINK that we are not supposed to use SHALL. So that leaves us with statements of fact or status - things that must be true for something to conform.

[rachaelbradley]

Technical Statement Active Statement Examples

• Completing steps in a process do not require a cognitive test such as remembering a password or solving a puzzle or calculation.
• Content supports customization
• When there is a timeout, a mechanism exists that allows users to disable or extend the timeout.

[rachaelbradley]

Assertive/Instructional Statement Examples

• Provide content that supports customization
• Label sections of content with clear visual and programmatic labels
• Indicate decorative images

[rachaelbradley]

Where/What/Why Statement Examples

Abbreviations and Acronymns

• Where: All abbreviations and acronyms
• What: The meaning of these terms can be expanded
• Why: Users with cognitive and learning disabilities have a way to recall the meaning of text.

Timeouts

• Where: A timeout exists in a task/workflow
• What: The timeout can be disabled, extended, or avoided by using an alternative path (with NO timeout) to complete the same task/workflow.
• Exception: The timeout is essential.
• Why: Users with visual, fine motor and cognitive disabilities have a way to complete a task before timeout.

[GreggVan]

The "where what why" -- is actually close to what is in EN 301 549 now. There we have "conditional clauses" followed by the requirement. and then notes. I would suggest we use this format but not necessarily with the words Where What Why but with that structure. They are also now putting the conditions on a new line - but keeping them as part of the sentence

Perhaps (for something with three conditions)

<Title of provision>
Where this is true and this is true and this is true,
the following is true.
Notes:
Rationale: put the why here including benefits
- -- though it might be better to put the why in a separate document since there rationale (or why) will often involve multiple disabilities and require explanation and example to understand.

Also It allows the why to be improved or exanded over time as things change and as comments come in from people who don't understand.

[mraccess77]

I agree that these 3 questions are useful and important to map - I believe any type of logical statements like where this is true and then this would be too complex for a document like this. This type of language is good for tests like ACT rules. So I would think this is best for explanation of the outcome and not as the outcome itself.

[rachaelbradley]

Summary for AG Meeting 13 February

Short Summary:

Based on the conversation to date, we will be begin today's discussion with the three formats that received the most support (thumbs up) and 0-1 concerns (thumbs down). We will discuss the others if needed:

• Technical Statements (6 thumbs up)
• Where, What, Why Statements (3 thumbs up)
• Requirements Statements (4 thumbs up, 1 thumbs down)

More Details

Based on votes and comments, three formats seem worth exploring more in the meeting:

Technical Statement

• 6 for, 0 against
• Example: Completing steps in a process does not require a cognitive test such as remembering a password or solving a puzzle or calculation.
• Key Comments: None

Where What Why Statements

• 3 for, 0 against
• Example: Abbreviations and Acronymns
  -- Where: All abbreviations and acronyms
  -- What: The meaning of these terms can be expanded
  -- Why: Users with cognitive and learning disabilities have a way to recall the meaning of text.
• Key Comments
  -- The "where what why" -- is actually close to what is in EN 301 549 now. There we have "conditional clauses" followed by the requirement and then notes. I would suggest we use this format but not necessarily with the words Where What Why but with that structure. Where this is true and this is true and this is true,
the following is true.
Notes:
Rationale: put the why here including benefits.
  -- I agree that these 3 questions are useful and important to map - I believe any type of logical statements like where this is true and then this would be too complex for a document like this. This type of language is good for tests like ACT rules. So I would think this is best for explanation of the outcome and not as the outcome itself.

Requirements Statement

• 4 for and 1 against
• Example: Completing a process shall not require remembering a password, solving a puzzle or calculation, or passing another cognitive test.
• Key Comments:
  -- We should strive for plain language, and the requirement statement is closest to the current SCs
  -- I was surprised how much I disliked the use of shall. Active voice reads better.

The other formats received no support or an even amount of support and concerns:

• Needs statements: 7 against
• Question statements: 6 against
• User statements: 4 for and 4 against
• Assertive/Instructional Statement: 2 for 2 against