RE: Adaptive Image Element Proposal

> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
> > Adrian Roselli, Thu, 30 Aug 2012 18:24:54 +0000:
> >> From: Leif Halvard Silli
> 
> >> For toolmakers, it seems - to me - simpler to just let
> >> img@aria-labelledby point to the picture element. (Or, eventually,
> >> point from picture to img - but then we need validation rules for the
> >> picture element - instead.) Getting WYSIWYG tool *duplicate* alt
> >> attributes ... my guess is we will never see them do that. But I
> >> could be wrong.
> >
> > I disagree.
> 
> I should add that I had some kind of automated duplication mind, so that the
> author don't ned to think about the issue, especially the issue of keeping in
> sync.

I had the same thing in mind.


> > [ snip] given
> > the confusion I see about ARIA and its support, I don't see toolmakers
> > approaching it as readily as just duplicating @alt.
> 
> BlueGriffon has supported ARIA for a while. I don't think it is alone in
> supporting ARIA ... Doesn't Adobe Dreamweaver support, for example?
> Of course, authors could retype the alt value, manually. I predict this will not
> happen often ... I also predict that we will, generally, see aria-labelledby
> support before we see <picture> support (however, this perhaps counts as
> nothing more than a wild guess).

Web content isn't just created by web developers. So very much of it is created in browsers with WYSIWYG controls that something like Dreamweaver (if it even has ARIA support) only goes so far. In the case of a CMS, the vast majority of that content is being entered by non-web folk, which means they are using WYSIWYG editors like CKedit (which does not have any ARIA that I could find) and others.

I am trying to keep in mind the marketing assistant who has to upload a press release and embed a picture as part of it. He/she is likely doing it via a CMS and a browser-based WYSIWYG. Those are the tools about which I am most concerned.


> >>>>  <figure>
> >>>>   <ficaption>Caption</figcaption>
> >>>>    <picture>
> >>>>     <source src=files >
> >>>>     <img src=file >
> >>>>    </picture>
> >>>>  </figure>
> >>>
> >>> Your example has not @alt anywhere. Trying to stay in the scope of
> >>> the <picture> element proposal, I think it is missing two @alts.
> >>
> >> Confer the spec:
> 
> >> http://dev.w3.org/html5/spec/the-img-element.html#img-good
> >
> > That language lives in the clause: " If the src attribute is set and
> > the alt attribute is not [then...]" I do not take that to mean a
> > missing @alt is legal but simply how the browser should behave when it
> > has been omitted. I don't feel that overrides 4.8.1.1.1 " Except where
> > otherwise specified, the alt attribute must be specified and its value
> > must not be empty; the value must be an appropriate replacement for
> > the image. "
> 
> OK. Then check the figure element example in the section "Graphical
> representation of some of the surrounding text". [1] Or try the validator. [2]

I must be confused about your example. 4.8.1.1.6 leads off with the statement "[T]he alt attribute must be present but its value must be the empty string." That tells me there must still be an @alt on the <img>. Your validator example appears to say the same thing.

I am of the opinion that in your example the <img> should have an @alt. According to the new <picture> proposal, the <picture> should also have an @alt of the same value as the <img>. I'm not seeing anything in the spec that disagrees with the first part of what I said, so perhaps we aren't talking about the same thing?


> [1]
> http://dev.w3.org/html5/spec/the-img-element.html#a-graphical-
> representation-of-some-of-the-surrounding-text
> [2] http://tinyurl.com/validinsidefigure

Received on Thursday, 30 August 2012 19:07:56 UTC