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

Hello Daniel,
Thank you for your responses.
I am fine with all that you suggest and changed.
Best
Sylvie

--

Sylvie DUCHATEAU
Experte accessibilité numérique 
09 72 45 06 14 — 06 62 33 68 12
Expertise et formation en accessibilité numérique
access42.net — Formations — Newsletter
Organisme de formation référencé au DataDock
et certifié Qualiopi pour sa démarche qualité


-----Message d'origine-----
De : Daniel Montalvo <dmontalvo@w3.org> 
Envoyé : mardi 26 juillet 2022 12:57
À : Sylvie Duchateau <sduchateau@access42.net>
Cc : wai-eo-editors@w3.org
Objet : RE: [wbs] response to 'Curricula: Content Author Modules Monkey Review'

Dear Sylvie,

Thanks for your comments, and sorry for the late reply.

Please see my replies below. The updated draft is at

https://content-author-modules--wai-curricula.netlify.app/curricula/content-author-modules/


> > 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. 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.

The TF discussed this in our 5 July meeting.
https://www.w3.org/2022/07/05-wai-curricula-minutes.html#t05


We felt this structure follows the pattern for the other parts, where we start with the basic and most relevant knowledge for the target role and then we dive into the more advanced bits.

From a developer perspective it makes sense what you suggest. But we feel content should be the key aspect courses for content authors should focus on, so it makes sense for us for clear content to come first.

> 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...

Included in teaching ideas, last bullet of topic "Easy to Understand Language".

> 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.

EO had a related discussion for the "How to Make Your Presentations and Meetings Accessible to All" resource. My recollection is that even in the more technical fields there is room for simplicity. The example we discussed is the one from NASA's most recent image descriptions at
https://twitter.com/NASA/status/1546621144358391808


> > ---------------------------------
> > 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:
> 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.

You are right that there does not seem to be a consistent way for authoring tools to render table summaries and descriptions. The idea that I think should be relevant for content authors is that there is a short description and a long description, and these two have different purposes. Also, not all tables need a long description.

But I don't think we should get into much technical detail for the content author modules.

I changed topic "Table Summaries and Descriptions", teaching ideas, last bullet to:

"Introduce accessible authoring tools that produce appropriate markup for table summaries and descriptions. Some tools may refer to summaries as "titles" or "names". Some tools may refer to descriptions as "descriptions" or "captions". Others may have just one "caption" field".

Which I think covers what you said above. What other suggestions do you have to make this clearer?

>  Regards,
> 
>  The Automatic WBS Mailer

--

Daniel Montalvo

Accessibility Education and Training Specialist W3C/WAI

Received on Tuesday, 26 July 2022 12:13:31 UTC