Re: DRAFT response Re[2]: Request for PFWG WAI review of Omitting alt Attribute for Critical Content

Hi, Al

Gez lemon wrote:
"I think it's important to ensure accessibility errors are rectified as
soon as possible. We all know that accessibility works best when it's
considered from the outset, and I don't see the sense in temporarily
overlooking it. Addressing the issue now could help ensure that other
premises aren't built on an already faulty premise, and that tools are
not developed on this premise. Ultimately, it would save a lot of time
and put everyone on the same page if serious accessibility issues are
addressed as and when they're found."

I concur wholeheartedly with these assertions and would appreciate a
response from WAI and PWFG on this.


On 27/11/2007, Gez Lemon <gez.lemon@gmail.com> wrote:
> Hi Al,
>
> > ** yes, that bit of editorializing by the editor is inapropriate.
> >
> > * bad technology assessment
> >
> > The suggestion to shift the burden to machine-vision technology
> > in the assistive technology is not reasonable given the state of
> > the art.
>
> Even with more sophisticated technologies, such as image scanning, it
> would take some artificial intelligence to determine the author's
> intent of a critical image with missing alt text.
>
> > * not respecting roles and missions (charters) of different groups.
>
> I didn't really understand the rest of the reply from here. I think
> you're saying that the HTML working group have made a bad premise that
> critical alt text may be omitted completely, but it's not worth
> telling them just yet, as they have more pressing issues to deal with.
> If I have misunderstood your response, could you phrase it in very
> simple terms so that I can follow.
>
> I appreciate that the HTML working group have a lot to deal with, but
> I think it's important to ensure accessibility errors are rectified as
> soon as possible. We all know that accessibility works best when it's
> considered from the outset, and I don't see the sense in temporarily
> overlooking it. Addressing the issue now could help ensure that other
> premises aren't built on an already faulty premise, and that tools are
> not developed on this premise. Ultimately, it would save a lot of time
> and put everyone on the same page if serious accessibility issues are
> addressed as and when they're found.
>
> Apologies if I've completely misunderstood your response.
>
> Best regards,
>
> Gez
>
>
> >
> > The quoted remarks from the Editor's Draft would put HTML5 in
> > conflict with WCAG, and WCAG is chartered to produce Recommendations
> > on this topic.  Point, paragraph.
> >
> > The question in the quote is a matter of format usage, not format
> > engineering.  The answer is a matter of access policy, not format
> > engineering.  So by the charters, WCAG wins.  Strike the remark.
> >
> > It's ill-considered editorializing by an individual and shouldn't be a big
> > deal to get rid of.
> >
> > * second, why I didn't address this head on.
> >
> > I don't see why the issue page [1] accepted the terms in the quote
> > from the current Editor's Draft as defining a real issue for the HTML
> > Spec.
> >
> > The notion of 'critical content' is not used in developing the ALT
> > text requirements in WCAG2, Guideline 1.1.  They are more concrete
> > than that and for good reason.  One consumer's 'critical content' is
> > another author's 'eye candy.'  The WCAG WG took years to come
> > up with the language they have.  HTML WG has enough of a problem
> > coming to consensus on questions that HTML5 does have to address;
> > don't let the process in HTML WG get bogged down in yet another
> > re-invention of that wheel.
> >
> > So the "core issue" is IMHO a non-issue.  The necessary edit to
> > the draft is a simple matter of applying the charter and WCAG and
> > clean it up.
> >
> > I went through the roundabout dance of function and performance
> > requirements because it is still appropriate for HTML5 to re-consider
> > whether the best way to mark content that is "Decoration, Formatting,
> > Invisible:" is with no @alt attribute at all or with an explicit null string
> > as the value of the @alt attribute.  Either of those choices, once
> > offficially stated, is arguably a way to support what WCAG says.
> >
> > But "When is it appropriate to have meaningful content in @alt?" is
> > addressed and settled by WCAG. HTML5 should stay out of that
> > conversation other than to support the policy from WCAG with markup
> > that enables readily-used techniques.
> >
> > Al
> >
> > >[1] http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/0044.html
> > >[2] http://www.w3.org/html/wg/html5/#the-img
> > >
> > >On 25/11/2007, Al Gilman <Alfred.S.Gilman@ieee.org> wrote:
> > >>
> > >>  <note
> > >>  class="inDraft onProcess">
> > >>
> > >>  Earlier discussion on this point can be reviewed at
> > >>  http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/thread.html#msg44
> > >>  http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/0012.html
> > >>
> > >>  Please comment on this on the XTECH list.
> > >>
> > >>  PFWG could reach consensus on some variant of this
> > >>  statement as early as Wednesday, 28 November or
> > >>  it could take longer depending on the nature of the
> > >>  commentary.
> > >>
> > >>  </note>
> > >>
> > >>  <premises>
> > >>
> > >>  Let's note the following:
> > >>
> > >>  WCAG2 is likely to become a recommendation before
> > >>  HTML5, and is reasonably likely to be a Rec for several
> > >>  years before HTML5.
> > >>
> > >>  The Web has been under-performing as regards supplying
> > >>  good ALT text for images since 1997 when HTML4 was
> > >>  published with a syntactic requirement for @alt on all <img>
> > >>  elements.
> > >>
> > >>  </premises>
> > >>
> > >>  <position>
> > >>
> > >>  HTMLWG should agree that authors SHOULD provide
> > >>  good text alternatives for all <img> elements as
> > >>  stated in WCAG2 Guideline 1.1.
> > >>
> > >>  provisional URI:
> > >>  http://www.w3.org/WAI/GL/WCAG20/#text-equiv
> > >>
> > >>  </position>
> > >>
> > >>  <position>
> > >>
> > >>  WAI should agree that well-placed informative references
> > >>  to existing W3C accessibility Recommendations is a
> > >>  suitable way for the HTML5 specification to address this,
> > >>  more or less as it has been done in the Specification Guidelines
> > >>  Recommendation.
> > >>
> > >>  http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#address-other-topics
> > >>
> > >>  </position>
> > >>
> > >>  <position
> > >>  class="requirement">
> > >>
> > >>  WAI asserts that HTML5 should provide formal semantics
> > >>  bound to some markup pattern which enables a readily-followed
> > >>  technique for the part of Guidline 1.1 where it says
> > >>
> > >>  <quote
> > >>  cite="http://www.w3.org/WAI/GL/WCAG20/#text-equiv-all">
> > >>
> > >  > Decoration, Formatting, Invisible: If it is pure decoration, or used
> > >>  only for visual formatting, or if it is not presented to users, then
> > >>  it is implemented in a way that it can be ignored by assistive
> > >>  technology.
> > >>
> > >>  </quote>
> > >>
> > >>  WAI suggests that the markup pattern
> > >>
> > >>     @alt=""
> > >>
> > >>  is a 'cowpath' in the language of the HTML5 Principles, in that
> > >>  assistive technology is already in the practice of recognizing
> > >>  <img> elements with that @alt value as ignorable.
> > >>
> > >>  <note
> > >>  class="inDraft">
> > >>  Somebody please confirm or deny this.  Do screen readers
> > >>  actually skip images with @alt=""?
> > >>  </note>
> > >>
> > >>  </position>
> > >>
> > >>  Al
> > >>  /self (chair hat off)
> > >>
> > >>
> > >
> > >
> > >--
> > >with regards
> > >
> > >Steve Faulkner
> > >Technical Director - TPG Europe
> > >Director - Web Accessibility Tools Consortium
> > >
> > >www.paciellogroup.com | www.wat-c.org
> > >Web Accessibility Toolbar -
> > >http://www.paciellogroup.com/resources/wat-ie-about.html
> >
> >
> >
>
>
> --
> _____________________________
> Supplement your vitamins
> http://juicystudio.com
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Tuesday, 27 November 2007 12:09:32 UTC