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

Thanks Daniel,

Looking forward to seeing this one being published :)

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: Wednesday, 7 September 2022 7:09 PM
To: Andrew Arch <andrew@intopia.digital>
Cc: wai-eo-editors@w3.org
Subject: 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/co

> ntent-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-contro

> ls-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:35:52 UTC