<cyns> I'm on skype, can you hear me?

<janina> No

<cyns> i can hear you. I'll troubleshoot

<cyns> looks like I have a driver problem on win7.

<cyns> will listen and type

<inserted> ScribeNick: Gez

JS: What to do about machine generated text

<cyns> code again

<cyns> ?

JR: Try and force non-validity on something other than a missing alt on HTML5

<Loretta> 92424

GV: How can you determine whatever is there - validity is not the same as conformance - how do you get a machine to determine between machine and non-machine generated?

JS: No way to decide if alt string is good bad or indifferent
... Not just case for machine generated - also case for human generated string
... Regardless of how generated - we don't have a way to enforce quality
... We can just make stabs at what has happened. A number of proposals, but would just put us in a debating and difficult debating position. Smarter path is to state it is present, but says nothing about quality

<janina> ack

LR: Real issues is what should the code look like if there is nothing provided by a human?
... Proposal that text should not be provided when none available - if we agree, it should be stated explicitly

<cyns> point 1) this is also true for other HTML elements. there is no way to check that <p> has a topic sentence or is any other way a proper paragraph. Only a human can do that. Point 2) There are some situations where a well-designed AT can make a pretty-good guess on what the alt should be. This is an area that needs research, not a ban

<cyns> can someoen read that?

<Jan> LGR: Read cyns

KF: The machine case is no different from a human that doesn't care about alt
... Distinguishing between human and machine is not relevant
... IN Flickr case - photo 1 and photo 2 is better than nothing

JS: I can point you to a website where the alt text is always, "Put your text here"

KF: I've seen examples where humans have typed in irrelevant alt text

GV: There are examples where machine can do better than human

<janina> Glad you're here!

<janina> It was cancelled.

LGR: Want to avoid situations where alt text is badly generated - but should be encourage people to omit which would be invalid - or encourage communication that there is no alt text provided

<Zakim> MichaelC, you wanted to say machine-generated alt can be better than nothing, so I'd like to steer clear of saying you should omit and be invalid; what we need is a

GV: Question to Loretta - Are you saying something is put in that is recognisable, or asking if alt needed?

<oedipus> loretta, would a role="missing" - as a generic token - work in this AND other cases?

LGR: alt needed, but open to discussion

GV: What if you don't have good alt? We just create a standard way of saying, we don't have anything useful

<Loretta> gregory, that is a possibility

GV: Something besides just sticking something in to become valid
... If it looks what we believe is machine, the only thing a validator can do is check if something there - cannot check quality

<cyns> another example: If there are 50 clickable thumbnail photos, knowing that this link opens photo 5 of 50 makes the UI far more usable than hearing an unnamed link or a long, complex URL of the storage location of the image. In this case, the tool does know the purpose of the image. The alt text is providing the name of the link. <a href><img alt="1 of 50"></a> has an MSAA role of "link" and a name of "1 of 50". This might even be the correct alt text for the thu

<cyns> I think it is possible that in some circumstances a well-designed authoring tool could do better than a poorly-trained human.

<cyns> thumbnail

<cyns> for the thumbnail, even if a human had provided descriptive alt text for the full-sized photo. It might even pass WCAG. Another point: I'm ok with a machine-generated flag, but should be removable when the machine did a good job, perhaps verified by human. And another: role=missing would mess up API mappings, so I don't think it works. role needs to be "image" or "button" or some such.

<Loretta> acks cyns

<Zakim> cyns, you wanted to say that I think it is possible that in some circumstances a well-designed authoring tool could do better than a poorly-trained human.

<MichaelC> +1 to cyns

JR: Authoring tools should not make repairs unless it can add information that would not be available textually to user agent
... So not grab filename of image

JS: SO we should point to the ATAG guideance?

<Zakim> oedipus, you wanted to say role="presentation" says no alternative text provided or needed; role="img" says alternative text MUST be provided

<oedipus> 1. alt is for humans: both on input and output sides - human consumption and human insertion

<oedipus> 2. consider role="missing" - as a generic token - in this AND other cases

<oedipus> 3. OR: @alt for human input/output ONLY; @role for classification; @type for machine insertion and error flagging (type="missing" or type="invalid")

GV: Question to Gregory - what would be valid what you said? Valid for type="missing"?
... Only thing in image is role="missing" would that be valid?

GR: Valid, not accessible

<oedipus> valid, but inaccesible

GV: That would satisfy HTML WG - it would then be up to WCAG not HTML5's concern

<oedipus> valid, but inaccesible if type="missing" or type="incomplete" or type="invalid"

GV: So long as it's valid to say missing, we should write that down as an option

<oedipus> if role="img" (explicitly or explicitly) WITHOUT @alt, then type="missing" or type="incomplete"

<Jan> to ask what is labelled with type=missing...the whole image? How does the UA know it refers to the alt attribute not something else?

<oedipus> type="machinegenerated" type="mg" type="auto"

GV: Marking something as machine generated allows you to check. Maybe a second proposal is to have something called machine generated as a type, and you allow the machine to put in something alt.

JS: Some way of flagging alt generated, so long as not part of alt string

GV: type="machine_generated" allows machine to put things in

<oedipus> the problem is that even if human or machine generated alt text needs a human evaluation to ascertain if valid/accessible

GV: Over time, we may be able to do quality generated alt
... alt for human consumption, but couldn't suggest machines could never do good

<cyns> +1 GV

GV: They could do a better job than humans in the future

<oedipus> if one can keyboard navigate to all images that need to be converted (problem with webvisum's CAPTCHA buster - have to be able to put focus on CAPTCHA)

KF: Disagree that alt is strictly for human - other ways alt text can be there that are valid or could become valid
... Machine generated flag that could be changed to human - concern is that a level of complexity has been introduced that makes people thing it's more complicated than it is or should be
... Also concerned abnout benefit of identifying where alt text came from
... I have an application that allows me to create a photo album. I have an application on the web that allows me to extract that data as meta data. That would be machine generated

GR: It's not machine generated, as it originated from a human

KF: I disagree - how do you determine?

<oedipus> WCAG should champion embedding meta-data (terse and long descriptors) in image file formats

<cyns> I can go either way on the machine-generated flag. However, I really worry about where to draw the line. If you have a back-end system that's generating a page, it might very well know exactly what the purpose of each image is.

<cyns> I'd like to see authoring tools track this, but I don't think it needs to be in the markup.

<cyns> perhaps ATAG AA?

<cyns> It was discussed on the HTML list, but i don't think there was consensus

<cyns> yes

<Loretta> acks cyns

<Zakim> cyns, you wanted to say where do you draw the human vs. auto line, though? Is an image button on a template machine generated when the template is used on a page?

JR: What does type="missing" on the image refer to?

GR: Whatever is attached

JR: What if it was source? It's ambiguous

GR: The term we used - don't mind what it is, but the type flag should be thrown when alt is missing

<oedipus> type="needsalt"

<oedipus> type="needssrc"

<Loretta> is "type" already used in HTML5/ARIA?

JR: I understand. I see some usefulness in marking something like this. We could have good automatically generated alt text in situations that are highly understood by the tool. Such as when it asks for a photo of owner

GV: The only time you would use type="machine" would be something a human wouldn't need to do
... Adds to complexity, but solves a problem that has taken thousandss of hours that no one has solved
... A little bit of complexity, but just for machines that solves this problem

<oedipus> type="noalt" and type="nosrc"

GV: type="missing" - change to missingalt, but purpose is for when machine couldn't make a meaningful guess
... The type suggestions add complexity only for machines, and only for the purpose of allowing something to be valid, but not accessible

<Zakim> oedipus, you wanted to say the subtly is that even if source of the alt text is human OR machine, alt text still needs human evaluation to ascertain if valid, pertinent, correct,

KF: There was talk about setting type="machine" that would trigger a human to check they were valid, and then update them or say they were okay- which would later be changed to human. How do you determine they're okay?

GR: This is a case where are meets science. We're never going to get a scientific explanation about what constitutes good alt text

KF: Not disagreeing - but at some point a human needs to look

<oedipus> i'm not sure how type="machine" got into my proposal - it wasn't in my 3 points

KF: I don't strongly oppose another group wanting to do this, but I'm opposed to this being mandated for accessibility

<oedipus> 1. alt is for humans: both on input and output sides - human consumption and human insertion

<oedipus> 2. consider role="missing" - as a generic token - in this AND other cases

<oedipus> 3. OR: @alt for human input/output ONLY; @role for classification; @type for machine insertion and error flagging (type="missing" or type="invalid")

JS: Clarifying - what happens when a human tweaks it? Does it get updated

<cyns> +1 kelly

KF If the HTML5 WG want to propose that - fine - I'm against us forcing this on them. Too much complexity for not enough benefit

<Zakim> Ben, you wanted to say, "1) What is advantage to user from a user experience perspective of missing flag? 2) Is it reasonable to expect that authors would use it?"

<oedipus> machine generated flag is a canard - it's not my idea nor part of my proposal

GR: It's not about machine generated flags. A missing flag is something AT could use
... A user may want to specify how they hear alt - no alt, give me title, no title give me something else

<cyns> I just don't agree that machine-generated alt is never good. whether it has been checked by a human is a workflow issue.

<cyns> not a UI issue.

<oedipus> i'm not asserting it is good or bad, it still needs to be reviewed

<Loretta> acks cyn

<Zakim> cyns, you wanted to say why does this have to be in the markup? Why can't the authoring tool track it internally? It sounds like workflow to me, not UI

<oedipus> gives users ability to use tools like GreaseMonkey and AccessMonkey

GV: What good is it to say flagging it as machine? It helps maintain pages, helps checking pages, gives users ability to decide how they receive information

<oedipus> amen, gregg

<oedipus> note: queue is closed

<janina> proposal: We do not oppose so kind of flag that indicates alternative text was machine generated, as long as this flag is not included in the alternative text string itself.

<Laura> got the time confused

GV: What we have is a nice compromise that doesn't force them to take alt off required, but also addresses human generated alt

<Laura> what is the phone code?

<cyns> I agree with Ben. I think a lot of site owners would consider this to be putting a big "sue me" sign on their backs.

<Zakim> cyns, you wanted to say I agree with Ben. I think a lot of site owners would consider this to be putting a big "sue me" sign on their backs.

LG: If they're worried about being sued - provide adequate alt text

<cyns> Yes, this is just like noalt in that respect. I dont' think many will use it.

JS: Straw poll

<cyns> I don't see it in IRC

<Jan> proposal: We do not oppose some kind of flag that indicates alternative text was machine generated, as long as this flag is not included in the alternative text string itself.

<oedipus> can live with - still think machine-generation is a canard, though

<cyns> can live with.

<oedipus> VERY wise phrasing, janina -

<Loretta> can we provide this flag with no text alt?

<cyns> don't understand loretta's question?

<oedipus> only if role="presentation"

<Loretta> would providing the flag make the img valid?

<oedipus> er, i mean, role="img"

<oedipus> collecting low hanging fruit

<cyns> aren't those the same?

LG: Thought proposal about missing was better than type="missing". Does this replace that?

<oedipus> general statement of principle

JS: No

JR: Idea is to get something that will validate that says something truthful about how much you can trust the alt

JS: Agreed

<oedipus> @alt for human input/output ONLY; @role for classification; @type for machine insertion and error flagging (type="missing" or type="noalt" type="nosrc")

JS: Doesn't indicate it was provided in an authoring environment

<cyns> that was nicely put, Jan. Perhaps we could add that to the proposal to help explain our reasoning?

GV: Use of this flag is when not presentational

GR: Yes, changed

GV: We need these things together, as separately they don't make sense

<oedipus> GJR: meant role="img" -- long week

<cyns> point 1) @role needs to be image, unless it's being used as a button or some such. Otherwise, you mess up API mappings by overloading role.

<cyns> point 2) I'm really confused about what Greggory is proposing

<cyns> can you put in some markup examples?

<cyns> that was nicely put, Jan. Perhaps we could add that to the proposal to help explain our reasoning?

<oedipus> cyns, will take some time

<Loretta> acks cyns

<Zakim> cyns, you wanted to say I thought this served the same purpose as type=missing. If not, I don't understand type=missing.

<cyns> I'm done talking, but still confused <grin/>

<oedipus> cyns, that's because you're in magical madrid

<cyns> Jan's comments about saying something truthful about alt quality

<Zakim> Gregg, you wanted to say, "In order to address both the validity and human generation concerns, we do not oppose the creation of a 'machine generated' and a 'missing' flag and that

<cyns> liked the first one better. this is too specific in the names of the flags.

<cyns> why not keep it simple?

<cyns> I could live with and/or, but am not convinced we need both

<Ben> scribe: Ben

<oedipus> 1. img has implicit role="img" UNLESS author changes to role="presentation"

<oedipus> 2. img with no alt text is an implicit (or explicit, if added by authoring tool) type="noalt" - this is valid HTML5, but inaccessible web content

<oedipus> <img src="image01.png" type="noalt"> (implicit role="img")

<oedipus> <img src="image01.png" alt="Cynthia Shelly"> (implicit role="img")

<oedipus> <img src="expand-collapse.png" role="presentation">

<oedipus> <img src="image33.png" role="img" type="noalt">

<oedipus> <img role="img" alt="The Grand Canyon at sunset." type="nosrc">

JS: wonder if what we're really looking at is 2 sets of proposals, the second is having some kind of indicator that alt needs to be present and was not provided

<oedipus> cyns, do those help?

GV: point was that we should capture both ideas. not sure we're in a position to insist on anyting, but sending this we're simply asking them to do it this way. not quite sure how they would differ. in each case we're politely suggesting.

<oedipus> morrass is the correct term

<cyns> oedipus, how does an implicit noalt do anything that missing alt attribute doesn't? if noalt is implicit, then doesn't that make img with a missign alt valid?

<oedipus> i can support that

LGR: this is our suggestion for how to create valid code in this situation

<Loretta> cynthia, what implicit noalt?

GV: Not sure anybody would use the missing. I think authors may label as machine generated, but missing woudl be useful if you're trying to flag things to go back and clean up later.

<oedipus> cyns, it prevents authors or authoring tools or content management tools from stuffing placeholder or meaningless text as an alt value

<cyns> So, did I understant Loretta correctly? We prefer for alt to be a required attribute of img, but don't oppose a noalt flag as long as it is not part of the alt string. Is that right?

<Loretta> oh, you meant explicit.

01In order to address both the validity and human generation concerns, we do not oppose the creation of a 'machine generated' and a 'missing' flag where either one of these could be used to make an image valid without any human-generated text alternatives.

<Loretta> alt or labelledby or legend, but yes

<oedipus> should that be part 1 of a 2 part statement - here is principle and limits of acceptable advice, here is our recommended declarative markup approach

01In order to address both the validity and human generation concerns, we do not oppose the creation of a 'machine generated' and a 'missing' flag where either one of these could be used to make an image valid without any human-generated text alternatives.as long as this flag is not included in the alternative text string itself.

<cyns> I like Loretta's idea. State that we prefer that alt be a required attribute of img and area. But, we don't oppose a mechanism that allows several alternatives (alt, role=presenentation, aria-labeledby) or noalt.

<oedipus> the subtly we have to convey is that even if the source of the alt text is human OR machine, alt text still needs human evaluation to ensure it is: valid, pertinent, correct, unique or identical, accessible, understandable-in-isolation

01In order to address both the validity and human generation concerns, we do not oppose the creation of a 'machine generated' and a 'missing' attribute where either one of these could be used to make an image valid without any human-generated text alternatives (as long as this marker is not included in the alternative text string itself).

<oedipus> it is as much an art as a science

<Loretta> except that I don't prefer that alt be require!

<cyns> oh, I thought you did. I do :-)

<cyns> oops, sorry about the smiley

<oedipus> type="auto"

<Loretta> I don't want to be required to provide alt if there is already a perfectly good label available.

<cyns> ok, that's fair. I guess the part I'm not sure about is just the noalt.

<oedipus> agree with kelly - keep text, remove parentheses

<oedipus> Note: This marker MUST NOT be included in the alternative text string itself.

<cyns> not includign it in the @alt attribute string is a very important part of what we're saying.

<cyns> +1 greggory

<kford> The first sentence sounded awkward to me. I've lost the text from my irc window.

<oedipus> Note: Such a marker is NOT be included in the alternative text string itself.

01In order to address both the validity and human generation concerns, we do not oppose the creation of an 'autogenerated' and a 'missing' attribute where either one of these could be used to make an image that does not have any human-generated text alternatives valid. (Note: it is important that this marker is not included in the alternative text string itself.)

<oedipus> Note: Such a marker is NOT to be included in the alternative text string itself.

<oedipus> GJR prefers more assertive phrase at end, because that is the meat of the matter

01In order to address both the validity and human generation concerns, we do not oppose the creation of 'autogenerated' and 'missing' attributes where either one of these could be used to make an image that does not have any human-generated text alternatives valid. (Note: It is important that this marker is not included in the alternative text string itself.)

<cyns> reading, one sec

<janina> +1

<oedipus> (lukewarm) plus one

<Jan> +1

<cyns> can live with

<kford> +1 to proposal.

<Laura> cold plus one

RESOLUTION: Add the following to the proposal, "01In order to address both the validity and human generation concerns, we do not oppose the creation of 'autogenerated' and 'missing' attributes where either one of these could be used to make an image that does not have any human-generated text alternatives valid. (Note: It is important that this marker is not included in the alternative text string itself.)"

<oedipus> logistical question: should these minutes be public or member?

<scribe> ACTION: Gregory to draft "second paragraph" for above. [recorded in http://www.w3.org/2009/04/24-cg-minutes.html#action01]

<trackbot> Sorry, couldn't find user - Gregory

<oedipus> scribe: Gez_Lemon, Ben_Caldwell

Next meeting?

JS: Proposes next Friday, 1pm Zulu

<janina> Ben, can you wrap the minutes?

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JR/JS/
Succeeded: s/JR: Clarifying/JS: Clarifying/
Succeeded: i/JS: What to do/ScribeNick: Gez
Found ScribeNick: Gez
Found Scribe: Ben
Inferring ScribeNick: Ben
Found Scribe: Gez_Lemon, Ben_Caldwell
Scribes: Ben, Gez_Lemon, Ben_Caldwell
ScribeNicks: Gez, Ben
Default Present: Janina, JR, Gregg_Vanderheiden, kford, Cooper, Gez_Lemon, Loretta_Guarino_Reid, Cynthia_Shelly, Gregory_Rosmaita, +1.218.349.aaaa
Present: Cooper Cynthia_Shelly Gez_Lemon Gregg_Vanderheiden Gregory_Rosmaita JR Janina Loretta_Guarino_Reid kford Laura_Carlson
Regrets: Joshue_O_Connor
Got date from IRC log name: 24 Apr 2009
Guessing minutes URL: http://www.w3.org/2009/04/24-cg-minutes.html
People with action items: gregory

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.