W3C

Site Navigation

Nearby

Results of Questionnaire Publishing Making Content Usable

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-03-12 to 2021-03-23.

14 answers have been received.

Jump to results for question:

Publish Making Content Usable

1. Publish Making Content Usable

With these changes, are you comfortable with publishing Making Content Usable?

Summary

Choice	All responders
Choice	Results
Yes, publish Making Content Usable	10
Yes, with the following changes	4
No, for the following reasons

Details

Responder	Publish Making Content Usable	Comments
Charles Hall	Yes, publish Making Content Usable
Sarah Horton	Yes, publish Making Content Usable	The document is very valuable in its current format and I am responded with an enthusiastic “Yes” to publish. It’s a rich toolkit full of ways designers and developers can incorporate attention to the needs of people with cognitive and learning disabilities into their practice. Excellent work—thank you for doing it! That said, it’s a lot to take in. I am concerned that the intended audience might not readily pick up and start using the resources. I have some feedback and suggestions that might enhance its usability, accessibility, and usefulness. These are suggestions that, in my opinion, are not required to publish. Provide document overview section: The Introduction would benefit from a document overview section at the start that lists the primary sections of the document and provides a brief description of the purpose and contents of each section. Something like this: - User Stories: This section contains user stories describing different needs of people with cognitive and learning disabilities. Each story is provided with a set of user needs. - Design Guide: This section presents a framework for addressing the needs of people with cognitive and learning disabilities. The guide is organized by objectives, each with patterns to support the objective. Patterns are provided with rationale, how-to guidance, and testable examples. - Usability Testing, Focus Groups, and Feedback: TBC - Use Cases / Personas: TBC Provide descriptive links: In “2.1 How to Use this Document” (and throughout the document) change the section links (e.g., Section 5) to descriptive links. For example, using the underscore character to identify link text, change “Agile teams can incorporate _section 3_ into their user stories” to “Agile teams can incorporate the _user stories in section 3_ into their user stories.” Group key sections: Recommend moving the User Cases / Personas section before the Usability Testing, Focus Groups, and Feedback section. The User Stories, Design Guide, and Use Cases / Personas are an excellent toolkit for designers and developers. Refine testing and evaluation content: The content related to testing and evaluation is excellent and important, but seems less well developed. The “2.1.1 Testing Each Pattern” section does not appear to belong in the “2.1 How to Use this Document” section at its current level of detail. The content is important and would be helpful in the Design Guide. Suggest removing for this version and adding an item to the ordered list in the “2.1 How to Use this Document” section, “8. Examples from each pattern can be used as the basis for test cases.” The section on “2.3 Building the User into the Development Process” in the Introduction and the section on “Usability Testing, Focus Groups, and Feedback” seem less integrated than the other content. Recommend removing for this version and working to build a section on testing, combining test cases and evaluation with people with cognitive and learning disabilities. Write this section to integrate with the Design Guide for testing and evaluation, and with the User Stories and User Cases / Personas for generative research activities. Remove unnecessary content: Appendix B Considerations for Different Contexts and Policies could be removed given the target audience is designers and developers. Some small tweaks: - 6.9 Tal: A Student who has Dyslexia and Impaired Eye Hand Coordination, Tal uses they/them pronouns but their use cases uses their name everywhere, rather than pronouns. Revise the text to use pronouns. For example: “Having navigated the online library system, Tal finds a paper about Post-war fashion. Tal downloads it in PDF format. Tal likes to use a text-to-speech application to read the content aloud, but when Tal tries to highlight the text nothing happens.” Change to: “Having navigated the online library system, Tal finds a paper about Post-war fashion. They download it in PDF format. Tal likes to use a text-to-speech application to read the content aloud, but when they try to highlight the text nothing happens.” - In the Objectives section, the sentence “This also includes the following user needs” does not have a clear subject. Is it, “This user story also includes the following user needs?” Suggest making clear what “this” refers to throughout. - There are some editing tweaks needed (not many!), e.g., content that is difficult to understand: “I need to touch the controls I intend to. The interface is designed so that I rarely touch controls by accident”. Also, some needs aren’t bulleted and some are bulleted at different indentation levels, and it’s not clear whether it’s intentional. I’m happy to do editing suggestions on GitHub if that would be helpful. I would learn a lot by reading it closely!
Lisa Seeman-Horwitz	Yes, publish Making Content Usable
Jennifer Delisi	Yes, publish Making Content Usable
E.A. Draffan	Yes, publish Making Content Usable
Abi James	Yes, publish Making Content Usable
Michael Gower	Yes, with the following changes	A proof for consistent style should be carried out. For example, there is inconsistency in capitalization of headings and terms (sentence case versus headline case). Also, it needs a copy edit for agreement between subject and verb, etc (For example., " Clear headings, boundaries, and regions also helps people ..."). Actually, it could also use a structural edit to consider the structure and navigation features. It's a big document and is hard to digest or navigate in its current form. To illustrate that progressive realization that the document needs some more attention, below are a couple of issues that jumped out at me in the Summary section. It looks like the first item under Summary isn't numbered. Shouldn't there be nine items, the first one being "Help users find what they need"? And then in the same section, although the "See also" material _is_ numbered from the top, it gets very confusing because it doesn't match the existing numbering. It makes it look as if the See also section precedes the section. Further, note that the last item is NOT numbered Note also the indentation lacking in the first "See also" Rather than have "See also: user needs, design patterns, mappings to scenarios, and user testing for objective...." after each of your Summary subsections, I recommend you provide a short paragraph explaining the structure of each section. It should be a lot easier to parse than this repetition; it is not immediately obvious that the 36 links, which only have 4 unique names between them, actually point to 36 different locations. I assumed they were each just pointing to the same 4 requirements, 9 times! It actually might even be an idea to have a separate list of contents for each section at the start of each section (similar to how they are provided at the top of each SC) to make the structure clearer and assist people who learn better consistently with one of the subsections.
Jake Abma	Yes, publish Making Content Usable
Laura Carlson	Yes, publish Making Content Usable
Sukriti Chadha	Yes, publish Making Content Usable
Bruce Bailey	Yes, with the following changes	Please address issues identified by Detlev and Mike G.
Rain Breaw Michaels	Yes, publish Making Content Usable
Detlev Fischer	Yes, with the following changes	There is a lot of good information in this document. The use cases / personas seem to cover a good range of conditions and situations. However, the document is extremely long, and I wonder whether a segmentation would be beneficial. I noted some things that may be improved. 1. “People with cognitive cognitive and learning disabilities often use add-ons or extensions as assistive technology”. Is this so? Are there pointers to empirical research? 2. There are structural weaknesses. For example, there are links that have too little context to be useful - take for example the paragraph “Section 5 can be useful for teams involved in user research and user testing” - why? Do I have to scroll down to section 5 to find out what it is about? 3. There are redundancies that make the content confusing. Take for example the fact that in “How to use this document” there are three different bullet points starting with “Design patterns”, recommending different uses (for requirements specifications, design guidelines/libraries, and content guidelines, as point 2, 6 and 7). Another example: Section 5 announces the following content in two bullet points: - special considerations and support for professionals working with this group and - a brief introduction support for people who are new to usability testing(...) However, there are no subsections with headings matching the content announced. Going over the following headings, it is unclear whether they belong to one or the other, or cover something different. Certain important topics such as conflicting user needs are touched but not followed by advice. I am not sure if this is because there is no good solution, because it is too much dependent on specifics, or if the authors shy away from admitting that designs may be by necessity compromised (in making compromises) so as to ruffle no feathers. In section “5.2 Finding People to Include” we find the claim that “Finding people (...) with different cognitive and learning disabilities can be achievable, even for small groups on a low budget. People sometimes recruit users from an organization or self-help group for people with learning difficulties”. In our experience, it is often not achievable, or only with considerable difficulty. Many users with cognitive disabilities users do not fit into the typical usability settings. Intermediaries which users trust are often needed. Direct observation may be ruled out as unduly affecting the comfort of use, indirect observation may also be ruled out for ethical or privacy reasons. This is not to say that such research is impossible, I just want to emphasise that it is hard, poses significant methodological problems, and is probably out of reach to most typical design and development contexts. It would be good to see this clearly acknowledged, better even constructively discussed, in a paper like this. The point above makes me wonder whether the statement “all teams should try to involve users with cognitive and learning disabilities throughout the design and development process” is generally achievable and also, the most productive in terms of design outcome. Would it not be more productive to try to develop clear design best practices from an aggregation of in-depth research which can do justice to the different groups and the methodological difficulties, rather than expecting designers to delve into usability testing themselves? I know that designers can learn a lot from usability testing so I don’t want to discourage that at all, but the results given the usually small numbers of participants may be somewhat arbitrary. Details: I stumbled at the passage „voice menus that involve remembering a specific number or term“. Is a ‘voice menu’ any menu that can respond to spoken commands, say, in Dragon? That wouldn’t be anything special. Or is it something else I don’t know? I guess many people will be uncertain what this means. Another detail regarding the graphic in section §4.3.3.3 How it Helps: I don't think the graphic here is helpful it is far too abstract / has too little context to illustrate the point.
David MacDonald	Yes, with the following changes	I think we need a sentence such as this: "This W3C Note is not Normative and is not recommended to be required by laws or general policy for entire sites because it is not possible to satisfy all the recommendations for some content."