- From: Daniel Montalvo <dmontalvo@w3.org>
- Date: Sun, 31 Jul 2022 17:11:16 +0200
- To: <andrew@intopia.digital>
- Cc: <wai-eo-editors@w3.org>
Dear Andrew, Thank you so much for such a detailed review. Sorry for the late response. Updated draft is at https://content-author-modules--wai-curricula.netlify.app/curricula/content-author-modules/ See also some follow-up comments below and a couple of questions. > > --------------------------------- > > Content Author Modules Overview Page > > > > ---- > > Please focus on Content Author Modules Overview Page. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author > > Modules Overview Page. > > > Comments: > 1. Consider changing "... effectively use websites and applications" to "... effectively understand and use websites and applications" Done. > 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'? We do have specific topics on form labels and instructions, as well as on link text, which I think make the distinction clear. I have added, though: "text (including text passages as well as label and link text)" > > --------------------------------- > > Content Author Module 1: Clear Content > > > > ---- > > Please focus on Content Author Module 1: Clear Content. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author > > Module > > 1: Clear Content. > > > Comments: > 1. The intro sentence for topic 1 Easy needs the first word capitalised - "Easy to understand language ..." Done. > 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. Fair point. Now we no longer say, "an authoring tool of their choice" but "a given authoring tool". This puts the responsibility on the instructors to decide what authoring tool they would use in their courses and removes the idea that students can choose one on their own, which rarely happens. Will give it a thought to include the idea on possible work-arounds. > 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. I will rewrite this topic to include this, as well as other visual references that are not very clear. > > --------------------------------- > > Content Author Module 2: Structure > > > > ---- > > Please focus on Content Author Module 2: Structure. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author > > Module 2: Structure. > > > Comments: > 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] Done. > 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 Fair point. Changed to: "Practical — Have students visit a page with an inaccessible heading hierarchy. Ask students to identify inaccessible examples and to propose accessible alternatives for the inaccessible examples. Assess how students identify inaccessible heading hierarchies and propose accessible alternatives". > 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. I don't understand your point here, could you clarify? > 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 :( We don't really get into specifics of how assistive technologies render these lists. You are right, on the windows side of things. VoiceOver, however, does make the distinction. This is overall good practice that we have mentioned in the developer modules. It seemed reasonable for the TF to include these here as well. > 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 :( That's true if you want to get to the beginning/end of a document or web page. But if you want to go to the beginning of the section or straight to the TOC, that's not that easy. This may deserve clarification. Changed LOs to: "ensure availability of methods for users to move through different sections in long passages of text, for example using: [...]" I will take another pass and get back to you when this is done. > 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? That's what we were getting at. I am not sure what the problem is here. We have mentions to footnotes in the intro, learning outcomes, teaching ideas, and assessment ideas. What do you think is missing here? > > --------------------------------- > > Content Author Module 3: Forms > > > > ---- > > Please focus on Content Author Module 3: Forms. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author > > Module 3: Forms. > > > Comments: > 1. Suggest that that first dot point also mentions error messages in > addition to instructions and labels. Done. > 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. I've placed these two adjacent in order. > 3. Topic Labels: Instead of "surname" can we use he more generic "family > name" please :) Done. > 4. Topic Labels: should we include discussion about the pitfalls of > placeholder text in form fields? Not sure we should include this in the content author modules. We do have this on the developer modules https://www.w3.org/WAI/curricula/developer-modules/forms/#topic-controls-and-labels Content authors provide the labels, but I wouldn't expect them to be changing the code at that level. > 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) Would it be better if we say: "Content authors or UX designers provide the labels/instructions"? > 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. Now changed to: "Demonstrate the use of voice commands, keystrokes, and gestures for assistive technologies to get to the instructions associated with form fields and controls. Explain that several groups of users require meaningful instructions to provide the appropriate input. Show how successful form interaction becomes difficult or impossible without such instructions". > 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. Done. > > --------------------------------- > > Content Author Module 4: Images > > > > ---- > > Please focus on Content Author Module 4: Images. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author > > Module 4: Images. > > > Comments: > 1. Resources should include "Inaccessibility of CAPTCHA - W3C" - > https://www.w3.org/TR/turingtest/ We don't have this resource in the other parts as we thought tutorials cover it. Do you think we should include it just in this one or also in developer and designer curricula? > 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." Changed to: "Informative images convey information visually, for example through 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 That LO discusses how to provide the alternative text for the images. Basically , you either include it in the images or provide it in the adjacent text. If we add that here that would make an extra-long sentence. Also, I think marking the image as decorative is a separate thing and may require collaboration with other team members. We have this down below. "collaborate with designers and developers to mark an image as decorative when it does not convey information" > 4. Topic Informative - assess: In the last practical, consider adding > "Assess what alternative text the students suggest for the images they do > consider informative" Thanks for bringing up that the distinction between informative and decorative should be clear. Changed to: "[...] Assess what text students select for the informative images, as well as how students distinguish informative from decorative images based on context". > 5. Topic Functional: in the intro adding some about icons often being > functional images. Added. "Discuss different approaches for providing text alternatives for functional images, including for icons as well as for graphical buttons and links". > 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. Will do. > 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) Changed to: "Emphasize that it is best practice to display instructions on how to get to the long descriptions on screen, as they are beneficial for all users". > 8. Are we missing a topic on Decorative? Task Force discussed this before and agreed that content authors had little to do in decorative images except for marking them as such and distinguishing them from informative. We cover both in the topic "Informative Images". Could you live with that decision? > > --------------------------------- > > Content Author Module 5: Data Tables > > > > ---- > > Please focus on Content Author Module 5: Data Tables. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author Module > > 5: Data Tables. > > > Comments: > 1. Should the intro bullets also say something about many people struggling > to understand the relationships in complex data tables? Will do. > 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 We are proposing now to change the scope of this to "identify situations where tables are used only for layout purposes" This qualifies scope, as it was not clear what the role of content authors would be for layout tables. It also helps distinguish between data tables and layout tables. > 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. That's right. We concluded that this falls under designer rather than content. > 4. Should the first Topic be about simple vs complex tables and the > advantages of simple table to all? We'd like to keep the structure as-is for this one, but I will take a pass to see if we can make this distinction come through clearer. > > --------------------------------- > > Content Author Module 6: Multimedia > > > > ---- > > Please focus on Content Author Module 6: Multimedia. > > * Are all points covered - is anything missing? > > * Is there anything in there that should not be in there? > > You can comment below or leave a GitHub Issue about Content Author Module > > 6: Multimedia. > > > Comments: > 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 ..." Done. > 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" "match audio and video content" was unclear for some. Based on combined feedback, changed to: "provide redundancy for different sensory characteristics to help different groups of users understand the content" > 3. SC 1.4.7 is missing from the WCAG list for instructors Included. > 4. Topic Transcripts - teaching: Explain that "descriptive transcripts" can > also be developed from the original script for a video. For more alignment with guidance provided in the media resource, changed to: "Explain that creating descriptive transcripts is easier if they are based on existing captions and description of visual information". > 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" Should not this be for topic captions instead? That topic is now updated to make sure we communicate that automatically generated captions are not sufficient to cover all user needs. > 6. Topic Captions - Learning outcome: Consider adding a note hat captions > can be added in multiple languages for selection by the user? Will do. > Regards, > > The Automatic WBS Mailer -- Daniel Montalvo Accessibility Education and Training Specialist W3C/WAI
Received on Sunday, 31 July 2022 15:11:21 UTC