w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: dmontalvo@w3.org
This questionnaire was open from 2022-06-15 to 2022-07-08.
17 answers have been received.
Jump to results for question:
The following is a monkey review survey for the curricula Content Author Modules.
This is the fourth curriculum in our series of Curricula on Web Accessibility.
Please review carefully the following pages:
For background on purpose and scope of this work, please check the Curricula Requirements analysis.
What you're reviewing is everything in the final draft.
Please comment in the below boxes or open a GitHub issue
Responder | |
---|---|
Kris Anne Kinney | |
Jennifer Chadwick | |
Andrew Arch | All comments below are for editor's discretion (unless otherwise flagged) |
Laura Keen | |
Brent Bakken | |
Michele Williams | |
Estella Oncins | |
Shawn Lawton Henry | woo-hoo! Exciting to see this coming along! |
Gerhard Nussbaum | |
Brian Elton | |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | |
Kevin White | |
Sylvie Duchateau | |
Dónal Fitzpatrick | |
Vicki Menezes Miller |
What level of review did you do?
Choice | All responders |
---|---|
Results | |
I thoroughly reviewed the materials. | 10 |
I skimmed them. | 2 |
I need more time and will review by the date provided below. | |
I didn't get to it and will not in the near future. I abstain from providing comment. (Reminder: This is the last review before the approval to publish survey.) | 3 |
(2 responses didn't contain an answer to this question)
Responder | Review level | |
---|---|---|
Kris Anne Kinney | I thoroughly reviewed the materials. | |
Jennifer Chadwick | I didn't get to it and will not in the near future. I abstain from providing comment. (Reminder: This is the last review before the approval to publish survey.) | Just a note to say thanks again for sending this through and I wanted to respond properly. Hope you're all well. Jenn |
Andrew Arch | I thoroughly reviewed the materials. | Looking forward to seeing this Content Author material published as I'm of the opinion that without good words, technically correct code still fails |
Laura Keen | I thoroughly reviewed the materials. | |
Brent Bakken | I didn't get to it and will not in the near future. I abstain from providing comment. (Reminder: This is the last review before the approval to publish survey.) | |
Michele Williams | I thoroughly reviewed the materials. | My comments are noted in GitHub. |
Estella Oncins | I thoroughly reviewed the materials. | |
Shawn Lawton Henry | I skimmed them. | I reviewed the Multimedia Module. So sorry that I'm not able to get to the others. |
Gerhard Nussbaum | I thoroughly reviewed the materials. | |
Brian Elton | I thoroughly reviewed the materials. | |
Jade Matos Carew | I didn't get to it and will not in the near future. I abstain from providing comment. (Reminder: This is the last review before the approval to publish survey.) | I'd like to prioritise making time to comment on the video sub group content. |
Carlos Duarte | I thoroughly reviewed the materials. | |
Howard Kramer | I thoroughly reviewed the materials. | |
Kevin White | ||
Sylvie Duchateau | I skimmed them. | Review completed. |
Dónal Fitzpatrick | ||
Vicki Menezes Miller | I thoroughly reviewed the materials. | A very valuable set of resources. |
Please focus on Content Author Modules Overview Page.
You can comment below or leave a GitHub Issue about Content Author Modules Overview Page.
Responder | Comments |
---|---|
Kris Anne Kinney | Any way to consolidate or collapse the prerequisite information? by this module, that list is getting long and I worry we may lose people there before they even get to the structure of the current module. Not a strong feeling either way - just wondering if anyone feels/felt the same? |
Jennifer Chadwick | |
Andrew Arch | 1. Consider changing "... effectively use websites and applications" to "... effectively understand and use websites and applications" 2. Should we call out that "text' is both long form (prose) and short form (micro-copy, eg labels), or is it covered sufficiently by 'forms'? And is link text covered by 'text'? |
Laura Keen | Overview looks good. It's covers everything and is easy to read. |
Brent Bakken | Overview page looks good. |
Michele Williams | |
Estella Oncins | |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Modules Overview Page' is ok for me. |
Brian Elton | |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | Looks good to me. |
Kevin White | Looks good |
Sylvie Duchateau | No comment on this page. I find it clear. |
Dónal Fitzpatrick | This page is well-written and presents an succinct overview. I noted one typo in the first H1: I think a space needs to be added between words 'modules' and 'in'. |
Vicki Menezes Miller | One suggestion in GitHub. For editors' discretion. |
Please focus on Content Author Module 1: Clear Content.
You can comment below or leave a GitHub Issue about Content Author Module 1: Clear Content.
Responder | Comments |
---|---|
Kris Anne Kinney | submitted thought in Github in case you wanted to take action on it. If not, just close it. Thanks! |
Jennifer Chadwick | |
Andrew Arch | 1. The intro sentence for topic 1 Easy needs the first word capitalised - "Easy to understand language ..." 2. The final suggested assessment idea for the Titles topic implies students would have a choice of authoring tool - all the people I've ever taught web content to have come form a work place and thus have their CMS provided by their employer. Consider rejigging the practical to asking them how their workplace authoring tool handles titles and link text and what they might have to do as work-arounds to do it better. 3. Topic Visual - is it appropriate to add mention proximity of headings and captions to their associated paragraphs or images as part of teaching ideas for readability? Maybe 'spacing' covers it, but probably worth calling out IMHO. |
Laura Keen | I'm confused by the * Accessible Authoring tools text after the Foundations Prerequisites link. Is '* Accessible Authoring tools' needed? When I select the Foundations Prerequisites link it takes me to the developer modules. I don't see anything obvious about authoring tools. Note: the Structure module has Accessible Authoring Tools as a separate bullet which makes sense to me now. Under heading "Topic: Visual Appearance" Missing "it" in the second paragraph first sentence in the phrase "they must ensure that it is accessible." When content authors can specify the visual appearance, they must ensure that is accessible. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | Comment on GitHub |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Module 1: Clear Content' is ok for me. |
Brian Elton | There is an odd character in the teacher competencies section (the last bullet point) - it is a back tick and asterisk, which seems incorrect, but also visually they are pushed together and appear as one character - "Foundation Prerequisites ` * Accessible authoring tools" (I think it is just supposed to me a new bullet point) In the teaching ideas for titles and links, the second bullet point has clunky wording - "This is why some authoring tools provide the same information in the page title and in the first heading of level one." Perhaps update to "This is why some authoring tools provide the same information in the page title and in the level one heading." (practicing what we preach and using the active voice) |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | It all looked good to me. For Optional ideas to assess knowledge of page titles, I would consider giving students a site to evaluate for page titles. Are they appropriate according to usability and accessibility guidelines (esp. WCAG, tutorials, Easy Checks), what should they be if not. The same for link text. Evaluating a real site is more interesting than a hypothetical site. The same could be done for link text. This exercise could also be used to assess knowledge for the entire module. |
Kevin White | Couple of GitHub issues and pull requests raised. Nothing major. |
Sylvie Duchateau | 1. Editor's discretion: I wonder if the order of teaching chapters should remain this way. Beginning the course with easy to understand language may discourage people. May be begin with the structure, titles, links clarity and end with language easy to understand. 2. What about recommending tools to check if the language is easy to understand? Some word processors contain readability tests or you could recommend dictionaries helping to look for synonyms, the explanation of acronyms and so on... 3. At last, may be indicate that in some situations, such as a research work from scientists or the final work of a doctor for medicine may no be rendered in an language that is easy to understand because it is a complex topic. I have no other comments for the rest of this page. |
Dónal Fitzpatrick | In the first learning outcome it states: "explain how clear, easy to understand, and easy to read content is essential for some people with disabilities". I would suggest that the wording of the learning outcomes for topic 1 be considered for inclusion here. My concern is that, as written, the benefits to a wide range of people with disabilities - and indeed all users - could be lost through the inclusion of the word 'some', with no clarification or qualification. I note a possible typographic/formatting issue in: "` * Accessible authoring tools" In Topic: Titles and link text I feel that there is an over-emphasis on the short answer questions to assess the topic. I wonder could alternative practical exercises be used instead. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Please focus on Content Author Module 2: Structure.
You can comment below or leave a GitHub Issue about Content Author Module 2: Structure.
Responder | Comments |
---|---|
Kris Anne Kinney | no comments |
Jennifer Chadwick | |
Andrew Arch | 1. Topic Headings: Suggest we drop 'rank' from "Headings and their corresponding rank levels communicate ..." In Australia we just talk about 'heading levels', not their 'rank' - having both words seems redundant (and thus jarred for me). [also in other parts of this section] 2. Topic Headings / Assess: the last Practical about "change the visual appearance of the heading" seems too technical for many content folk that I've worked with 3. Topic Paras and Lists: Can we add in the comprehension and skim-ability aspect of lists even though not WCAG related, especially suggesting that in-line lists should be called out as structured lists for these reasons. 3. Topic Paras and Lists: at this time, neither JAWS nor NVDA differentiate between the list item and it's definition in a Definition List. Not sure how we handle that here :( 4. Topic Orientation & Nav: We suggest that 'back to top' helps keybd users because "Otherwise, they would have to tab back through the whole document, which creates a poorer user experience." Surely most keybd only users know about CTRL-Home and CTRL-F? Just thinking aloud :) handle that here :( 4. Topic Orientation & Nav: The first time we mention footnotes is in an exercise - I presume we're asking students to think about what they've laernt to date and apply it here with a clickable link to the footnote and hen provide a link back to the starting place in he text where the footnote was referenced? |
Laura Keen | Looks good. Nothing to add. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | Comment on GitHub |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Module 2: Structure' is ok for me. |
Brian Elton | Not sure if intentional, but the Student competencies does not include "Prior Content Author Modules". The teaching competencies specifies module 1, so perhaps we need to look at a consistent way to refer to the other modules in all competencies sections. |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | Looks good to me. Similar to feedback for module 1, for optional ideas to assess knowledge of headings, paragraphs, lists, I would consider giving students a site to evaluate for each of these elements after each section or for all three for the entire module. Are they appropriate according to usability and accessibility guidelines (esp. WCAG, tutorials, Easy Checks), what should they be if not. |
Kevin White | Couple of GitHub issues and pull requests raised. Nothing major. |
Sylvie Duchateau | I have no comments on this section. It is clear. |
Dónal Fitzpatrick | The material presented in this module seems appropriate and is clearly presented. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Please focus on Content Author Module 3: Forms.
You can comment below or leave a GitHub Issue about Content Author Module 3: Forms.
Responder | Comments |
---|---|
Kris Anne Kinney | in the middle - will come back to it. |
Jennifer Chadwick | |
Andrew Arch | 1. Suggest that that first dot point also mentions error messages in addition to instructions and labels. 2. Learning Outcome: suggest "provide meaningful instructions that describe the overall purpose, intent and requirements of the form" - adding requirements (eg for password, phone number, etc with specific formatting or characters as appropriate). E.g. combine with "include instructions about expected input types and formats". Alternatively, place these two bullets adjacent in order. 3. Topic Labels: Instead of "surname" can we use he more generic "family name" please :) 4. Topic Labels: should we include discussion about the pitfalls of placeholder text in form fields? 5. Topic Instructions: "Content authors provide the instructions, designers specify their appearance. Developers implement the instructions." I've often found it is the UX folk that take responsibility to provide the instructions (and the labels) 6. Topic Instructions: suggest "Then demonstrate interaction with form fields and controls that do not have such instructions or have as visual instructions only. " raising the issues of have them associated programmatically with the label. 7. Topic Instructions: "Discuss with students which instructions they would provide" impies giving them several to choose from. Suggest "Discuss with students what instructions they would provide" instead. |
Laura Keen | Under Teaching Ideas for Topic second bullet first sentence, remove 'about': Show examples of about commonly used labels for form fields and controls. Under Ideas to Assess Knowledge for Topic First bullet - 'for' should be 'of' Ask students what type 'of' information instructions should contain. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Module 3: Forms' is ok for me. |
Brian Elton | all good |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | As above, this all looks good. And as above, I would again suggest the option of giving students a site to evaluate for the different topics discussed in this module. |
Kevin White | GitHub pull request raised. Nothing major. |
Sylvie Duchateau | I have no comments on this section. It is clear. |
Dónal Fitzpatrick | Topic: Labels The introduction to this topic highlights the collaboration needed between a range of stakeholders to define clear labels. I would suggest that a reiteration of the content found in the third learning objective, in respect of programmatic association, be made here. From reading this introductory text I feel that the need to associate labels with form controls (or other UI components) should be made more explicit. I note that this is a content-development module, however defining the correct label necessitates an understanding of the association with the form field, or group of form fields, to which it applies. In the second bullet point on teaching ideas for topic, I suggest removal of the word 'about'. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Please focus on Content Author Module 4: Images.
You can comment below or leave a GitHub Issue about Content Author Module 4: Images.
Responder | Comments |
---|---|
Kris Anne Kinney | |
Jennifer Chadwick | |
Andrew Arch | 1. Resources should include "Inaccessibility of CAPTCHA - W3C" - https://www.w3.org/TR/turingtest/ 2. Topic Informative: suggest changing "Informative images convey information, for example that of a picture or illustration." to "Informative images convey information, for example via a picture or illustration." 3. Topic Informative - Learning outcomes: Suggest adding to "adjacent text that conveys the same information as the image" something about marking the image as decorative in that case 4. Topic Informative - assess: In the last practical, consider adding "Assess what alternative text the students suggest for the images they do consider informative" 5. Topic Functional: in the intro adding some about icons often being functional images. 6. Topic Functional - teaching: add something about icons are not necessarily universally recognised and a word with an icon ensure it is understood by all. 7. Topic Complex - teaching: in bullet 3, 'how to access' the long description needs to be provided to all, not just via the shot description (I'm assuming alternative text when we say 'short description' - if we're referring to image caption, then ok) 8. Are we missing a topic on Decorative? |
Laura Keen | Looks good. Nothing to add. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Module 4: Images' is ok for me. |
Brian Elton | Not sure if intentional, but the Student competencies does not include "Prior Content Author Modules" Otherwise, all good. |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | Looks good. |
Kevin White | Couple of GitHub issues and pull requests raised. One significant issue, marked as 'high' in the title. |
Sylvie Duchateau | I have no comments on this section. It is clear. |
Dónal Fitzpatrick | In the first H1, I think there is a typo. Should the word 'in' be present? NO further comments on this module. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Please focus on Content Author Module 5: Data Tables.
You can comment below or leave a GitHub Issue about Content Author Module 5: Data Tables.
Responder | Comments |
---|---|
Kris Anne Kinney | |
Jennifer Chadwick | |
Andrew Arch | 1. Should the intro bullets also say something about many people struggling to understand the relationships in complex data tables? 2. Learning: suggest changing "collaborate with designers and developers to present multi-column content using CSS styles instead of layout tables" to "collaborate with designers and developers to present multi-column (non-data) content using CSS styles instead of layout tables" or similar 3. Should SC 1.4.10 - Reflow be included in this section for scrolling for tables on small screens? Though I presume that falls under design rather than content. 4. Should the first Topic be about simple vs complex tables and the advantages of simple table to all? |
Laura Keen | Looks good. Nothing to add. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | Comment on GitHub |
Shawn Lawton Henry | |
Gerhard Nussbaum | The content 'Author Module 5: Data Tables' is ok for me. |
Brian Elton | All good. |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | Looks good. |
Kevin White | Couple of GitHub issues and pull requests raised. Nothing major. |
Sylvie Duchateau | Most of the page is very clear. I only have one question: the page talks several times about summary and description. Methods are different according to what is used to create a table: On the web, summary and description are merged in the caption tag, if I remember correctly. When you create a table with a text editor, you may write a summary in the summary field and a description in the description field. But I am not sure if it is correctly rendered by assistive technologies. May be considered by editor, at editor's discretion how to talk about summary and description. |
Dónal Fitzpatrick | There is a typo in H1 between tables and 'in'. In the 'Learning Outcomes for module' it states: "collaborate with designers and developers to present multi-column content using CSS styles instead of layout tables". This is an excellent addition, however I submit that it is not just CSS styles which are utilised in the multi-column layout proposed. Inclusion of appropriate semantics also facilitates presentation of content in this fashion. I suggest consideration be given to explicit reference to markup required in conjunction with CSS to achieve this. I wonder whether it might be useful to consider inclusion of material in this module which outlines the differences between a data table and a layout-table. I note, for example, that no explicit definition of a data table is provided, so for some content authors it may be challenging to know when a table contains data, and when it constitutes a table used solely (or partly) for layout purposes. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Please focus on Content Author Module 6: Multimedia.
You can comment below or leave a GitHub Issue about Content Author Module 6: Multimedia.
Responder | Comments |
---|---|
Kris Anne Kinney | |
Jennifer Chadwick | |
Andrew Arch | 1. Consider changing the intro from "explain accessibility requirements for planning and including alternatives to audio and video content" to "... requirements for planning and delivering alternatives to ..." 2. Learning outcomes: Consider changing "match the video and audio information when possible to help different groups of users understand the content" to "match the video and audio information, including language, when possible to help different groups of users understand the content" 3. SC 1.4.7 is missing from the WCAG list for instructors 4. Topic Transcripts - teaching: Explain that "descriptive transcripts" can also be developed from the original script for a video. 5. 4. Topic Transcripts - teaching: consider adding in something along the lines of "Explain the draw-backs of relying on on a media player's auto-caption option" 6. Topic Captions - Learning outcome: Consider adding a note hat captions can be added in multiple languages for selection by the user? 7. |
Laura Keen | Second paragraph under Topic: Planning Audio and Video Link is broken: For details, see Planning Audio and Video. broken link - 1st bullet under Teaching Ideas for Topic For references on the accessibility requirements for different types of audio and video content, see Checklists for Audio and Video. broken link 2nd paragraph under Topic: Transcripts For details, see Transcripts. broken link 2nd paragraph under Topic: captions For details, see Captions/Subtitles. broken link 2nd paragraph under Topic: Description of Visual Information For details, see Description of visual information. |
Brent Bakken | |
Michele Williams | |
Estella Oncins | Comment on GitHub |
Shawn Lawton Henry | Comments in GitHub. |
Gerhard Nussbaum | The content 'Author Module 6: Multimedia' is ok for me. |
Brian Elton | All good. |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | |
Kevin White | Couple of GitHub issues raised. Nothing major. |
Sylvie Duchateau | I have no comment on this page. I find it clear. |
Dónal Fitzpatrick | There is a typo in the first H1 between 'multimedia' and 'in'. In the 'Learning Outcomes for module', I would have expected to see content relating to automatic playback of multimedia content, and the issues caused. I wonder could this be inserted just before, or after, the bullet-point on flashing content? I mention this because it is often the case that multimedia content which plays automatically can prove challenging to users of Assistive Technologies such as screen readers. In the competencies for students: Is there any need to mention a requirement to be somewhat familiar with the processes of multimedia creation? Note this is a minor point which can safely be ignored if desired. Also, this is mentioned in the context of instructors hence the suggestion to also include for students. In the 'Planning Audio and Video' topic, and to match the suggested addition to learning outcomes above, I would suggest adding material concerning automatic playback of audio/video, and ensuring that it does not happen. |
Vicki Menezes Miller | Comments/suggestions in GitHub. For editors' discretion. |
Use the space below to include any additional observations or concerns you would like to see addressed.
Remember: This is the last review before the approval to publish survey.
Responder | Additional Comments |
---|---|
Kris Anne Kinney | |
Jennifer Chadwick | |
Andrew Arch | Thanks for all the hard work on this - looking forward to having it available :) |
Laura Keen | Great work Daniel - such a valuable resource! |
Brent Bakken | |
Michele Williams | Wonderful job!! |
Estella Oncins | Great work! Really looking forward to the publication of this resource. |
Shawn Lawton Henry | |
Gerhard Nussbaum | Thenks for the excellent and valuable work. |
Brian Elton | |
Jade Matos Carew | |
Carlos Duarte | |
Howard Kramer | I will finish multimedia by the deadline or by Wednesday, June 30. What I've reviewed so far is excellent. |
Kevin White | |
Sylvie Duchateau | No additional comments. |
Dónal Fitzpatrick | n/a |
Vicki Menezes Miller | An excellent compilation of resources, a lot of work has gone into this. And great work, Daniel - really thorough! |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.