<scribe> scribe: slewth

Work plan -- different drafts, different purposes

Slewt+

Slewth+

<dmontalvo> https://wai-curricula.netlify.app/curricula/content-author-modules/ -> Frozen draft

<dmontalvo> https://content-author-modules--wai-curricula.netlify.app/curricula/content-author-modules/ -> Live Draft

How can we best communicate the responsibilities of content authors for decorative images? https://github.com/w3c/wai-curricula/issues/525

Daniel: Any questions before we start?
... Next agenda item. Module 4: decorative images. Carlos suggested adding a topic for better coverage.
... for context, the approach is to use topics based on types of image that designers are most involved with - not all kinds.

Correction - not designers - content authors

We need to discuss what kinds of things we expect in a topic on decorative images for content authors

they need empty alt-text, this needs to be taught, inclusive of rationale

e.g. Wordpress CMS - has checkbox for decorative, but not all tools have this

if we get into imagery overall, what is included what is not, that gets into the designers remit

need to be careful of overlap

What do people think we should be adding on decorative images from content author perspective?

Brent: Is there a place (not a whole topic) where decorative images can be mentioned?

Daniel: best place could be informative. difficult to make this decision - context dependent.
... could argue it decorative, others would say informative

Brent: make sense to move to informative. Is there a nice way in informative images topic to add a bullet or note about decorative - if ain image doesn't inform the user, here's how you should handle it
... does that work Carlos?

Carlos: where you push your image to be decorative because you describe it elsewhere on the page - but there are also scenarios where a conten author is managing a whole site via CMS...

I don't know if this is a design decision, but I can imagine people managing via CMS, adding decorative images - for decorative purposes. In that case, would be strange to be in 'informative''

Carlos: I agree with Daniels point. Explaining the boundary between decorative/informative
... how this should be handled. Annotated as a decorative image, or via CMS mark it as decorative.
... we don't need to go further for content-authors

Daniel: This was my understanding.
... that's a good point on annotations - not currently as clear as it could be.
... the first thing content authors should be able to discern is what type of image they're using

based on that if the image is conveying info you must use alt-text, if not, mark that as decorative, or make that annotation

Daniel: other comments?

Brian: For wording say 'redundant'
... so if attributing for article etc, the terminology could be whether the information in the image is redundant as it's already in the page.

This is a more common use case - is this image conveying info, yes it is, but that is already conveyed elsewhere?

Daniel: Yes, considering whether info is already in surrounding text, not purely about 'decorative'.
... So we're saying decorative require empty alt-text, and that relates also to adjacent text, and what is covered there. That appears to be two things. We can look if this can work integrated, without being a whole topic.

Is that a correct understanding?

Carlos: I agree.

Daniel: I'll update the issue. and
... bring back in agenda if needed.

Howard: I agree. It's hard to split what a content author will do, rather than a designer.
... I think of content authors working with the writing. Will they ever work with something that needs a description? In that case...that's the only thing that gives pause.
... Looking at other guides on writing we haven't talked about images at all
... I'm just bringing up that question

Daniel: Yes, tips for writing research is focussed on writing. We had this discussion at the outset...

we want to focus on the writing, but also extending to other use cases, although this is not the main focus

Daniel: including discerning concepts for learners using platforms - what they need to know...
... they need to know the content is covered. Finding balance is difficult

Brian: In the pure sense of copy-writer, content-author, they should be writing alt-text.
... Images are in their domain

Daniel: Most images would fall into that category.
... I'll try to include in what we have, discerning between informative and decoratiev, and guidance for instructors what empty alt-text means, and different ways empty-alt-text can be produced
... so it's clearer than it is at the moment.

More specific competencies https://github.com/w3c/wai-curricula/issues/518

Daniel: on student competencies...

We had a single phrase, accessible content creation, too generic, unclear...

so I'm proposing to have this into more specific competencies, for example...

copy-editing, proof-reading and based on the module we can have more specific competencies.

So writing, copy-editing and proof-reading and for exmaple, in context of forms, images- writing text alternatives, in multi-media, could be on scripts for video, audio. Trying to split between different things

scribe: based on module contents.

Daniel: How does this sound?

Carlos: I raised the issue. Yes, I do think it's an improvement.

Although the last set of competencies sounds to be competencies that they should be learning from their courses, not the basic knowledge that they should bring to modules...

scribe: so I agree, writing, copy-editing and proof-reading, but writing alt-text that should be learned, shouldn't be a basic competency,

Daniel: Yes, need to be careful
... I was looking for specifics, for last 4 modules. Trying to have specifics per module. But maybe we stick with what we have.
... the problem may not be lack of specificity, it may be that accessible content creation was too generic

Carlos: I'm not sure it's been understood - it was about the lack of specificicty on "content creation"

It's a fine line, between what students bring and what they should be taught.

Daniel: so writing, copy-editing, proof-reading is useful, but there is still some degree of specificity missing in final 4 modules where detail is introduced

I'll bring a proposal back.

I will add those three, writing etc. and I'll work on specific suggestions for other modules.

Daniel: Anything else?

Howard: I agree it's an improvement

Daniel: on multimedia module. Carlos suggested adding requirements for media players

to sum up we had the issue that content-authors should not be expected to make decisions about media players, that should be design/development roles...

we did not have this in development modules. We discussed in taskforce, we wanted to be agnostic on develop modules, and we didn't have the resource when writing the developer modules, but htere is an issue.

Developers should be aware - whether about coding, and accessible.

scribe: Media player is in the designers requirements. that controls are verbal, and can keyboard operate etc. but on developers - don't have this knowledge.

Becuase developing media resource at the same time, we didn't define what requirements would fall in different role based curricula

now we have the whole pictures, we are missing this in the developer modules.

scribe: we should not be expecting content-authors to be making decisions on media players.
... this needs to be issue for future iterations for the developers part - proposal is...

to make related requirements, for designers and developers, and mention in the content-authors but not require

Daniel: So keep as it is, and open issue that we return to Developer modules in the future.
... what do people think? Are content authors missing somethign on media players that we don't currently have

Howard: I agree. Across modules we say 'content-author should be aware' should be same in accessible media player. I agree
... the developer would be more responsible than the designers, but this is less relevant here.

<dmontalvo> V

Howard: I don't think the content-author needs to know in depth, just that it's important

Daniel: This is what we have.
... I propose to keep as is.
... When all are published, we will return to Developer modules.

Carlos: I raise the issue. Yes, I agree with proposed.

Daniel: to last agenda item.
... I'm attending to wider comments also, and working on these.
... Is there anything else to raise?
... we will meet again next week, specifically on teaching ideas on multimedia.
... also bringing back points and further comments that have been raised.
... thank you everyone!

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Howard, Brent, BrianE, CarlosD, slewth
Found Scribe: slewth
Inferring ScribeNick: slewth

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)