Ad Hoc HTML5-Alt -- 17 Apr 2009

<oedipus> don't worry gregg, i'm not minuting today

<scribe> scribe:jeanne

Rewrite of the Draft

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal (march 6 proposal submitted to WAI-CG)

JS: WAI-CG asked the working groups to comment on what was produced. One of which was that the report was difficult to understand. Gregg took on the task of simplifying
... another comment was that it wasn't clear whether we were requiring @alt for validity.
... Did we change our meaning in the re-write? We want consensus on whether there is consensus around the draft.

<Zakim> oedipus, you wanted to ask if there is a pointer to a static version of the revised proposal

GV: Today I put out a second version of the document adding some text that Michael suggested.

MC: I went through the drafts side-by-side and didn't see a meaning change. I sent comments on another issue, which Gregg has now incorporated.

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples

KF: We had additional discussion in UAWG thinking about user agents that have no need to support ARIA, such as mobile phones. How does this apply to browsers that do not support ARIA?

<oedipus> also, march 6 advice was conditional -- if aria-labelledby is supported natively...

JS: Let's first discuss whether the meaning has changed.

<Zakim> Question, you wanted to comment on UA that doesn't support ARIA

GR: We failed to communicate to our colleagues. If we aren't communicating this to UAAG, we need to clarify it.

<oedipus> RESOLUTION 1: We agree HTML5 should provide mechanism(s) for providing short text alternatives.

<oedipus> RESOLUTION 2: We agree HTML5 should provide mechanism(s) for providing long text alternatives.

<oedipus> RESOLUTION 3: We agree HTML5 should provide mechanisms to allow both short and long text alternatives at the same time.

<oedipus> RESOLUTION 4: We recommend continued inclusion of the "alt" attribute as a non-deprecated mechanism to provide short text alternatives.

<oedipus> RESOLUTION 5: That HTML5 state that "For guidance on accessibility requirements for text alternatives authors SHOULD consult WCAG 2.0." and that HTML should not provide any guidance that conflicts with WCAG.

GV: Your "if" statements were if ARIA was incorporated into HTML5. ARIA labelledby can not be included if ARIA is not.

GR: I was speaking to Kelly's concern that we could use @alt or ARIA labelledby.

GV: We are assuming that ARIA is included in HTML5.

<kford> \

JR: It wasnt just saying that the concern is only including ARIA in HTML5. There was also concern that some user agents would not support ARIA.

<oedipus> Principle 1: The working group recommends that HTML5 provide mechanism for both short and long text alternatives. (These are different concepts with different uses and both should be provided as separate functions. Short descriptions are read automatically when the item is encountered. Long descriptions are read only on request of the user.)

<oedipus> Principle 2: A short text alternative (using one of the mechanisms) should be required for validity but the long description should not be required.

<oedipus> Principle 3: We recommend continued inclusion of the alt attribute as one of the valid mechanisms to provide short text alternatives.

<oedipus> Principle 4: We recommend aria-labelledby as a second valid mechanism for short text alternatives.

<oedipus> Principle 5: We recommend: that HTML5 state that "For guidance on accessibility requirements for text alternatives authors should consult WCAG 2.0."; and that HTML should not provide any guidance that conflicts with WCAG

KF: Somehow there has to be awareness that, if this proposal is adopted, there will have to be awareness of the population that you are designing for. If you don't have a user agent that supports the latest technology, then you are running the risk that your site will not be accessible.
... the issue was also addressed in the UAWG comments on ARIA Last Call. There must be guidance and awareness that not all users will have the latest technology.

GV: We did say that you would be prompted to use @alt.

<Zakim> oedipus, you wanted to say would like to add: we recommend that HTML5 include a "role" attribute for IMG; the default value for an IMG is role="img" UNLESS the author changes the

LGR: We can't expect HTML5 to worry about subsets of the implementation of HTML5.

GR: recommend that HTML5 include a "role" attribute for IMG; the default value for an IMG is role="img" UNLESS the author changes the role value to "presentation" -- ALL images with role="img" are INVALID without alt

JS: this is different from what we agreed on before.

GV: [reads from proposal]

GR: We want continued use of @alt.

<Laura> From the original proposal:

<Laura> That the proper use of @role="presentation" be taken from ARIA 1.0 and that an IMG without a @role attribute is assumed to be the equivalent of <IMG @role="img"> (and would follow the rules in #1 above)

<Laura> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal#line-32

GR: No matter what, @alt is already in the spec. Therefore it must be used. ARIA Labelledby is conditional on being included in HTML5.

GV: I have added it to the document, that ARIA is included.

GR: Do we want ARIA hard-coded into HTML5? We will lose control of ARIA.
... we could use this document as a way to insure that @role is included.

JR: Assuming that ARIA is part of HTML5, are you ok with the "or"?

GR: Even if ARIA is part of it, we still need @alt as a fallback.
... we could ask older browsers to map labelledby to alt.

<greggvanderheiden> https://mywebspace.wisc.edu/gcvander/web/WCAG/WAI%20CG%20Consensus%20Resolutions%20on%20Text%20alternatives%20in%20HTML.html

<greggvanderheiden> That is the link to the edited version of what we are talking about.

Jeanne: HTML5 is being implemented and becoming a defacto standard before it is scheduled to become an official recommendation

<Joshue> Gregory has a good point about the piecemeal implementation.

JS: Does anyone object to the draft being accepted as not changing the meaning?

[no objections]

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/HumanImageProcessing

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

RESOLUTION: the draft of the second version does not change the meaning of the first version adopted.

<oedipus> thank you very much greggV

GV: I have added a sentence clarifying that ARIA must be adopted in HTML5.

JS: Would it be better to put some boundaries on that saying "the parts of ARIA referenced in this document must be included/"

KF: What we are ultimately saying is that we need to cross a bridge. @Alt doesn't work well enough to do everything that is needed. We are putting more of a burden on the author to insure that it is accessible.

<oedipus> don't want to stifle use of ARIA, just don't want to put all eggs in one basket that can't be modified/extended (i.e. hard-coded aria in html5)

KF: as long as there is outreach and awareness, that whatever environment you are in, does the general population have the ability to access HTML5 feature sets. I think we need to include that in our assumptions

JS: You are correct, we need to be concerned about people who aren't at the leading edge of the technology.

<greggvanderheiden> The statement isn't that are MUST be included but that we are assuming that it is.

<greggvanderheiden> NOTE: These recommendations are assuming that ARIA features referenced in this document are included in HTML 5.

JS: All the WAI groups need to be involved to educate on these issues.
... we don't want HTML5 providing accessibility guidance. It is raising possibility for conflict and misunderstanding.

<oedipus> summation from this morning's PF Caucus call on HTML5: "There MUST be a means of adding human parseable terse descriptors using alt or aria-labelledby. Tools like Flickr should aim for ATAG and WCAG compliance. Ideally, the author should be prompted to provide terse descriptors at load-time or pre-load, but definitely MUST provide a facility to attach terse descriptors to each image post-load."

JS: I don't think anyone is arguing that @alt will be forever sufficient. We have a vision that could do a better job than what was originally proposed. We can do a better job now with ARIA.

<Laura> +1 to oedipus:

KF: I don't know that this document is the way to raise those concerns. Recommendations on addressing legacy issues belong in a separate document

<oedipus> violet agreement - flower power!

JS: We are in agreement on this issue. We are not adding any additional statements on this issue for this document. We have documented in the minutes that this is an important issue
... and we need to address it as a later time. When it is ok to see more labelledby than @alt.

<oedipus> kford - check http://www.w3.org/2009/04/17-cg-minutes.html

<oedipus> jeanne logged as resolution

KF: Propose a resolution that CG sends appropriate guidance for proper use of ARIA labelledby as a result of this proposal.

GV: CG should provide guidance to the Working Groups to provide proper use of ARIA labelledby.

<greggvanderheiden> Propose a resolution that CG work with the working groups to see what can be done to ensure that guidance for proper use of ARIA labelledby be included in guidelines and educational materials.

<greggvanderheiden> Propose a resolution that CG work with the working groups to see what can be done to ensure that guidance on when it is effective to use ARIA labelledby be included in guidelines and educational materials.

[no objections]

RESOLUTION: that CG work with the working groups to see what can be done to ensure that guidance on when it is effective to use ARIA labelledby be included in guidelines and educational materials.

<oedipus> where does this advice belong?: "There MUST be a means of adding human parseable terse descriptors using alt or aria-labelledby. Tools like Flickr should aim for ATAG and WCAG compliance. Ideally, the author should be prompted to provide terse descriptors at load-time or pre-load, but definitely MUST provide a facility to attach terse descriptors to each image post-load."

are there improvements to the draft?

<oedipus> role="complementary" (or did i spell that wrong, MCooper?)

<greggvanderheiden> https://mywebspace.wisc.edu/gcvander/web/WCAG/WAI%20CG%20Consensus%20Resolutions%20on%20Text%20alternatives%20in%20HTML.html

JS: My concern was with the blanket statement that we are open to other engineering solutions. I think that weakens the document.
... It may be useful to say that where we are introducing new technolgies, but not as a blanket statement at the beginning of the document.

<oedipus> R-E-S-P-E-C-T

MC: The rationale is that if we just tell them how to engineer their specification, it will not be as effective.

<oedipus> i think we DO want to say you MUST use these

MC: We don't want to say "You MUST use these attribute."

GV: Delete the second sentence. We have in the background information information that these should be used as guidelines, recommendations, suggestions.

JS: I am happy with the second reference.

<JR> JR: I am happy with MC's original

<oedipus> if anyone can explain "their" process to us, i'm all ears

JR: I agreed with Michael's original. We need to signal respect for their process. We don't need to spend all day on this.

GV: It really does strengthen the document. We spent a lot of time to do it right, since it wasn't being done right. We don't want to have it dismissed.

JS: the later statement in the background doesn't water down our statement that this is what should be done.

<oedipus> we shouldn't forget that some of us are HTML WG members, too

JS: Are there any other perfections?

JR: I sent an email earlier today. It seems like there was so much front matter that people were overwhelmed with complexity before they even got to the meat of the proposal.
... moving it forward would improve the readibility of the document.

<kford> +1 to JR's move the key content up.

JR: the second bullet "proper use of role..." it just means that we want to use the "role" in ARIA, but it was mentioned in 1, that made it seem more complicated.

GV: The background says "this is what we are trying to solve" and then put the changes in. This is how we like to get comments in our WG.

JR: It makes it SEEM complicated, even though it isn't that complicated.
... for a regular author, it is the same workflow that they have now.

GV: Should I take the use cases and put that in as an appendix?

JS: I like that.

<JR> +1

<oedipus> all we need is a simple nav bar with jump-to links to each header

CS: Change "Background to "Goals"

<oedipus> amen +100

KF: Please be consistent about list numbering and lettering so it is clear.

<oedipus> add aria

<oedipus> mark notes as role="complementary"

Flickr use case discussion

JS: There was a comment that if we do not address the use case that HTML5 requested uidance on, it would appear that we were ignoring their concerns.

<oedipus> GJR suggests something short and sweet: "There MUST be a means of adding human parseable terse descriptors using alt or aria-labelledby. Tools like Flickr should aim for ATAG and WCAG compliance. Ideally, the author should be prompted to provide terse descriptors at load-time or pre-load, but definitely MUST provide a facility to attach terse descriptors to each image post-load."

JS: Should it be included in this document or a separate document?

<janina> fq?

LGR: We are saying that there has to be a text alternative. We need to address what to do when there is no suitable text.
... we are leaving ourselves open to null alt text in situations where the author did not provide text.

JR: I am open to there being a flag when the text is not available.

<JR> Use Case 1 (uncooperative author using a photo sharing site)

<JR> - author logs into the photo sharing site

<JR> - author uses the uploader feature to upload 50 pics of her vacation (XYZ0001.png, XYZ0002.png,..., XYZ0050.png) into an album she calls "Paris 2009".

<JR> - a prompt appears asking her to write descriptive labels for each image to facilitate text searching and access by people with disabilities.

<JR> - she ignores the prompt and logs off.

<JR> - The photo sharing site assigns the @alt strings "Photo 1 of 50 of album Paris 2009"

<JR> - when the user logs back in she still sees the prompt to descriptively label the images.

<JR> DISCUSSION:

<JR> + the page will be HTML5_valid because it includes @alt

<JR> + the feature will meet the PROPOSED ATAG2 requirement because the "After authoring session ended" repair used contextual information not available to the user agent.

<JR> + the page will NOT meet WCAG 2.0 because the text alternative does not serve the equivalent purpose

<JR> http://lists.w3.org/Archives/Public/w3c-wai-au/2009AprJun/0010.html

<oedipus> challange to HTML WG: validate ANY flickr page to see if (alt, aside) it is valid

JR: repair can only be information that is not available to the user agent (not file name).

<Laura> Flickr image pages currently have over 50 validity errors, and that's just HTML 4.01 Transitional.

<Laura> Why should the HTML5 make supposedly narrow exceptions to the spec to be more lax about validation when the sites themselves aren't even trying today?

<Laura> An author obviously has a responsibility in using an authoring tool.

<Laura> It is unreasonable to state that the output from authoring tools should always be considered valid, regardless of input or lack of thereof.

<Laura> Machine-generated patch-jobs and text alternatives originating from a person are not equivalent.

<Laura> The two aren't the same and shouldn't be confused or on purpose or otherwise.

CS: We can leave brand names out of it, but people understand the issue described as Flickr.

<oedipus> proposed "placeholder" alt - alt="i don't give a damn"

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/HumanImageProcessing

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

LGR: Is it reasonable to have a goal that authoring tools always generate valid output. It is implicit in our documents that there will always be a mechanism for providing accessible output.

GR: I am trying to get people to provide me with alt text for pictures that I took, and I would like a way to signal that I want alt text, and that it is still valid.

CS: Jan's use case is reasonable, and I think it is a useful case to analyze, and I think the HTML5 group thinks so too.
... What are the real steps that can be taken automatically and which steps can be taken by a human. That is key to getting agreement here.

GV: Jan's use case separates HTML5 validity and WCAG conformance. I think we should consider putting this example in.
... there is a new version of the document with this example. I think it is a very nice way of addressing the issue.

<Zakim> oedipus, you wanted to say counter-example to flickr is galaxyzoo

<Laura> Another proposal Machine Image Processing

<oedipus> astronomers seek help in describing galactic images - http://www.galaxyzoo.org/ - "This is a job that humans are much better at than computers, so most of the questions should be fairly easy."

GV: they might pick up on this example to separate accessibility and validity.

<Laura> http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

GR: Something we could add is galaxyzoo.org, because humans are better at describing pictures than computers.

GV: But they put images up without alt text.

<Laura> In HTML5 an author can provide an address with the address element that isn't a contact address, which would not be considered compliant.

<oedipus> plus 1 to laura's last comment

JR: A prompt is not a dialog where you have to say "dismiss, dismiss" It can be something that is unobtrusive.

CS: That is valid feedback for UAAG, but it doesn't need to be here.

LGR: We need to have a place where there is an image without alt, like the astronomers, or Greg looking for alt text for his photos. What do we want to see in the markup for those situation.

<oedipus> "photo 1 of 50" is as unhelpful as a naked filename "photo0001.jpg"

[jeanne reads Laura's comment]

JS: We need to be very clear that the current state of the art cannot be relied on for valid alternative text.

<oedipus> GJR's experiment in alt: http://my.opera.com/oedipus/blog/an-experiment-in-alt

CS: But we can get part-way there.

<oedipus> did i leave the lens cap on again - attempt to solicit alt for photos: http://my.opera.com/oedipus/albums/show.dml?id=212490

<Laura> What about proposing new attribute for machine generated alt or meta data?

KF: I am not comfortable with Use-Case 2 being an "uncooperative" author.
... proposed "Human generated" and "Computer generated"

<greggvanderheiden> document updated

KF: there is a concept of "readily achievable". If I take a 1000 photos, it is not reasonable to add 1000 alt text. I would rather have machine generated alt text.

GV: Make it a statement of fact, and actions or lack of actions.

<oedipus> need is two-fold: human parseable info and machine parseable info -- don't use alt to flag something missing - use role="img" to mark it invalid from machine processing PoV

<Laura> Machine-generated patch-jobs and text alternatives originating from a person are not equivalent.

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

<oedipus> GV agrees with LC's last comment

<oedipus> need is two-fold: human parseable info and machine parseable info -- don't use alt to flag something missing - use role="img" to mark it invalid from machine processing PoV

<Laura> Should use a different attribute to differentiate.

<greggvanderheiden> The example makes it clear that machine generated was valid but did not meet WCAG

GR: @alt is specific for describing an image. Machine generated text should be included in @role.

<Laura> Please check this proposal: http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

<oedipus> kford, you don't have to be 508 compliant, but if the site does...

KF: If there is no machine-generated text I am up a creek.

<oedipus> is there an end-time?

<oedipus> role="img"

LGR: what should the markup of that page be so it can be marked as needing @alt.

GR: I want @role="img" that would then be invalid.

LGR: Can we satisfy the HTML5 request that it be a valid page if the author refuses to cooperate.

GR: No. I want the AT to know that it is invalid.
... in the case of the astronomy site, they are saying that it is incomplete and they are asking for assistance in making them complete.
... I could put the coordinates of the picture, and others could describe the picture.

KF: Would a human have to write the coordinates?

GR: If they didn't type that it would have nothing and it would be invalid.

KF: I disagree.

<oedipus> how much longer are we going to run?

CS: This reminds me of the discussion of XML error handling and XHTML error handling.
... HTML doesn't want users to be exposed to error handling that only makes sense to highly technical users.

<janina> to the hour

<oedipus> it depends upon the grandma - if granny has blind grandkids, she WOULD have incentive to add alt for each and every image

CS: they would like something to be valid HTML and authoring tool innovators to innovate and add information.

<oedipus> just like granpa might caption his YouTube videos if he has hard-of-hearing or deaf relatives

CS: it is better than nothing, it is named and clickable without having URLs read. We need to allow for innovation in that space, because that can overall improve accessibility

<Laura> Metadata like that supplied with EXIF might helpful for machine image processing if it was offered in a SPEARATE image attribute.

CS: I don't think it is something that belongs in HTML but belongs in the Authoring tool.
... simplifing the experience of end users while giving developers the information that they need for debugging.

<oedipus> can people check out: http://esw.w3.org/topic/PF/XTech/HTML5/MachineImageProcessing

JS: Could people work on a document to capture the prevailing view to move us forward?

GV: I have posted the latest version and I would like to go with the version we have here.

<oedipus> if the meta-data is embedded in the image, yes

GV: we cannot say that all human is good and all machine generated is bad. We must separate validity from passing WCAG.

<oedipus> https://mywebspace.wisc.edu/gcvander/web/WCAG/WAI%20CG%20Consensus%20Resolutions%20on%20Text%20alternatives%20in%20HTML.html

<JR> JR: Rewording idea: 6. when the author logs back in they still see indicators on the images and/or the album that reminds them that the images are still lacking descriptive labels.

<oedipus> JR, yes, that's the idea

GV: We are going to have to reconvene. Do you want me to put some annotation next to the second case, so it doesn't look like final output, but still being discussed by the group?

GR: Do you have a problem with my linking from the XTech wiki to the document?

<oedipus> http://esw.w3.org/topic/PF/XTech

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5

GV: No, it is in a wiki space where it will be crawled, and I'll put it in a link where it automatically gives a password but the crawlers can't get to it.

JS: I recommend the CG call time at 2:30PM eastern on Wednesday.

<oedipus> thanks to jeanne for minuting above and beyond the call of duty!

[discussion of times]

<oedipus> kford, to edit the wiki, you need to create an account on the esw wiki - just go to http://esw.w3.org/

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/Caucus

<oedipus> kford, for schedule, minutes, agendas, etc.

11: 00 Eastern on Friday 24 April for 2 hours.

GV: It will last two hours if it has to.

Ad Hoc HTML5-Alt
17 Apr 2009

Attendees

Contents

Rewrite of the Draft

are there improvements to the draft?

Flickr use case discussion

Summary of Action Items

Ad Hoc HTML5-Alt 17 Apr 2009

Attendees

Contents

Rewrite of the Draft

are there improvements to the draft?

Flickr use case discussion

Summary of Action Items

Ad Hoc HTML5-Alt
17 Apr 2009