Outcome Formats #49
Replies: 8 comments 22 replies
-
|
User statement examples
|
Beta Was this translation helpful? Give feedback.
-
|
(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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to the first part of @alastc comment. 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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I think this approach has advantages, for example:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Needs statement examples
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
(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". |
Beta Was this translation helpful? Give feedback.
-
|
Requirement statement examples
|
Beta Was this translation helpful? Give feedback.
-
|
@alastc 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. |
Beta Was this translation helpful? Give feedback.
-
|
I was surprised how much I disliked the use of shall. Active voice reads better.
|
Beta Was this translation helpful? Give feedback.
-
|
@bruce-usab
were you contrasting these (in which case - how would you make the second one active) 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. |
Beta Was this translation helpful? Give feedback.
-
|
@GreggVan -- I just meant that I like both of these better than the imperative type of sentence. |
Beta Was this translation helpful? Give feedback.
-
|
@bruce-usab "I was surprised how much I disliked the use of shall" hard agree. makes it sound like some new testament commandments |
Beta Was this translation helpful? Give feedback.
-
|
Question Statement Examples
|
Beta Was this translation helpful? Give feedback.
-
|
My opinion, using the question format leaves a lot of wiggle room for people to rationalize answers. |
Beta Was this translation helpful? Give feedback.
-
|
(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. |
Beta Was this translation helpful? Give feedback.
-
|
+1 to alastc |
Beta Was this translation helpful? Give feedback.
-
|
Technical Statement Active Statement Examples
|
Beta Was this translation helpful? Give feedback.
-
|
Assertive/Instructional Statement Examples
|
Beta Was this translation helpful? Give feedback.
-
|
Where/What/Why Statement Examples Abbreviations and Acronymns
Timeouts
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Summary for AG Meeting 13 FebruaryShort 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:
More DetailsBased on votes and comments, three formats seem worth exploring more in the meeting: Technical Statement
Where What Why Statements
Requirements Statement
The other formats received no support or an even amount of support and concerns:
|
Beta Was this translation helpful? Give feedback.
-
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:
Summary from 13 February - Before AG Meeting
Beta Was this translation helpful? Give feedback.
All reactions