RE: [wbs] response to 'Curricula: Content Author Modules Monkey Review'

Hi Andrew,
I have now addressed all your comments.

Latest draft is at
https://wai-curricula.netlify.app/curricula/content-author-modules/ 

And the publication approval survey will open soon.

Best.

--

Daniel Montalvo

Accessibility Education and Training Specialist
W3C/WAI

> -----Original Message-----
> From: Andrew Arch <andrew@intopia.digital>
> Sent: Thursday, August 11, 2022 3:33 AM
> To: Daniel Montalvo <dmontalvo@w3.org>
> Cc: wai-eo-editors@w3.org
> Subject: RE: [wbs] response to 'Curricula: Content Author Modules Monkey Review'
> 
> Hi Daniel,
> 
> Thanks for considering all my feedback 😊
> 
> I've added a few comments (and clarifications) inline below - all starting with "AA:"
> 
> Regards,  Andrew
> ____________________________________
> Andrew Arch
> Principal Accessibility Consultant, Intopia
> p: +61 (0)447 389 137 | t: @Intopia  @amja Please note I only work Tuesday through Friday
> 
> 
> 
> 
> -----Original Message-----
> From: Daniel Montalvo <dmontalvo@w3.org>
> Sent: Monday, 1 August 2022 1:11 AM
> To: Andrew Arch <andrew@intopia.digital>
> Cc: wai-eo-editors@w3.org
> Subject: RE: [wbs] response to 'Curricula: Content Author Modules Monkey Review'
> 
> 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 &mdash; 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?
> 
> AA: real lists (that look like lists) are more skim able/scannable than inline lists AND require less cognitive effort to process. I regular see lists
> of things embedded in the para and the cognitive load is much higher than if they looked like an unordered list with one item below the
> other visually.
> 
> > 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.
> 
> AA: ok - but maybe add a caveat that not support by all common screen readers as at 2022?
> 
> > 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.
> 
> AA: thanks 😊
> 
> > 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?
> 
> AA: probably ok - was just clarifying
> 
> > > ---------------------------------
> > > 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.
> 
> AA: Just thinking it should be called out so that they can raise it with the devs if they find their labels have been implemented that way 😊
> 
> > 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"?
> 
> AA: excellent - thanks 😊
> 
> > 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?
> 
> AA: both places IMHO as it's such an issue for many of my friends and colleagues ☹
> 
> > 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 ensures 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?
> 
> AA: Sure
> 
> > > ---------------------------------
> > > 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.
> 
> AA: the one situation where content folk might add layout tables is in HTML emails where CSS doesn’t work as I understand, but all good
> with the change you're making
> 
> > 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.
> 
> AA: ok
> 
> > > ---------------------------------
> > > 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.
> 
> AA: ah, yes
> 
> > 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 Wednesday, 7 September 2022 09:08:43 UTC