RE: Discussion on Change Proposal for ISSUE-66

I think the change proposal is fine by it stands, and that
trying to supply any examples of alternate methods of determining
an image description needs to be evaluated against the rationale
of the proposal.

That said, if the images contain XMP metadata, you might consider
extracting the "dc:description" from the image metadata:
    http://www.adobe.com/devnet/xmp/


That would give a format-neutral way of obtaining author-supplied
metadata, it's just that it is supplied by the image author and
not just not in the HTML itself (and would work for other
formats as well.)

dc:description:
   A textual description of the content of the resource.
   values may be present for different languages.

probably most appropriate out of the Dublin Core schema
elements.

This would likely work better for sites that want static HTML
pages and to associate the image metadata (and alt text) with
the image itself as the image changes.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of John Foliot
Sent: Thursday, January 21, 2010 6:35 PM
To: 'Maciej Stachowiak'
Cc: Matt May; 'HTML WG'; public-html-a11y@w3.org
Subject: RE: Discussion on Change Proposal for ISSUE-66

Maciej Stachowiak wrote:
> 
> Examples: (a) read the filename, but only if it appears to
> be human-readable, not a stream of random letters and numbers; (b)
> perform OCR on the image, OCR these days is readily available and highly
> accurate; (c) provide the contents of relevant EXIF tags.

However Maciej, none of these can determine author intent, and at the end
of the day if a 'page' has an image inserted using the <img> element, then
it is there for a reason, and so that 'reason' needs to be expressed as
part of the alternative text - there is a cognitive requirement as well
that technology alone cannot deliver.

If there is a consensus to expose EXIF information using an explicit
attribute or element, then that's great (I personally don't think that
there is a need); suggesting that somehow that data might ever be
sufficient information to stand in for alt text is misleading and damaging
in the longer run. 

Here is some sample EXIF data, taken from an actual Flickr page:

Exposure:	0.017 sec (1/60)
Aperture:	f/3.1
Focal Length:	6.3 mm
Focal Length:	6.3 mm
ISO Speed:	400
Exposure Bias:	+1 EV
Flash:	Auto, Fired
File Size:	1998 kB
File Type:	JPEG
MIME Type:	image/jpeg
Image Width:	2400
Image Height:	3200
Encoding Process:	Baseline DCT, Huffman coding
Bits Per Sample:	8
Color Components:	3
Orientation:	Horizontal (normal)
X-Resolution:	480 dpi
Y-Resolution:	480 dpi
YCbCr Positioning:	Co-sited
Exposure Program:	Program AE
Date and Time (Original):	2010:01:18 10:15:03
Date and Time (Digitized):	2010:01:18 10:15:03
Max Aperture Value:	3.1
Metering Mode:	Multi-segment
Light Source:	Unknown
Color Space:	sRGB
Exposure Index:	400
Sensing Method:	One-chip color area
Custom Rendered:	Normal
Exposure Mode:	Manual
White Balance:	Auto
Digital Zoom Ratio:	1
Focal Length In35mm Format:	38 mm
Scene Capture Type:	Standard
Gain Control:	High gain up
Contrast:	Normal
Saturation:	Normal
Sharpness:	Normal
Subject Distance Range:	Unknown
Pentax Model Type:	2
Preview Image Size:	640x480
Preview Image Length:	38618
Preview Image Start:	15945
Date:	2010:01:18
Time:	10:15:03
Quality:	Good
Pentax Image Size:	Unknown (255)
Picture Mode:	Surf & Snow; 0
Flash Mode:	Auto, Fired, Red-eye reduction
Focus Mode:	Normal
AFPoint Selected:	Auto
AFPoints In Focus:	Top-center
Focus Position:	1005
Exposure Time:	1/60
FNumber:	3.1
ISO:	400
Light Reading:	18
Exposure Compensation:	+1.0
Metering Mode:	Multi-segment
White Balance:	Auto
White Balance Mode:	Unknown (0)
Blue Balance:	1.1953125
Red Balance:	2.1640625
Digital Zoom:	1
Saturation:	Normal
Contrast:	Normal
Sharpness:	Normal
DSPFirmware Version:	1.00.00.00
Image Processing:	Unprocessed
Data Dump:	(Binary data 2540 bytes, use -b option to extract)
Compression:	JPEG (old-style)
Orientation:	Horizontal (normal)

Can *ANYBODY* reading this note tell me what the picture actually is?


> 
> I am hoping we can find a happy middle ground by giving a general
> allowance for use of more information when alternative text is missing,
> or in general in the face of broken content, without overselling its
> capabilities. 

Let's turn this on its head for sake of discussion: would those who
believe this is a viable point of view feel the same way if the following
code:

	<img src="[broken path]" height="350" width="600" alt="Ford"> (and
yes, this is deliberately bad alt text, but not uncommon in the wild)

...allowed UA's to invoke their magic heuristic powers to seek out another
image of "Ford" that was about 350 X 600 pixels (from say Google's
gadzillions of indexed images), and replaced the 'missing image' with a
replacement image; do you think that the 'industry' and authors in
particular would find that an acceptable solution?  In many ways, that is
what is being suggested here; I mean, is substituting this 'ford.jpg'
image:

http://www.myrddin.it/merlino/mimg/ford.jpg  

...for this 'ford.jpg' image:

http://www.insidesocal.com/outinhollywood/ford.jpg  

...sufficient or appropriate? After all, they are both pictures of Ford...

When all is said and done, no technology today (or the foreseeable future)
can read minds, and so no amount of heuristic analysis can substitute for
author supplied alt text that delivers author intent.



> I think important considerations for that are: (1) don't
> get overly specific about the type of techniques to be used, or if
> examples are given, make sure they are squarely within the mainstream of
> current technology; (2) make very clear that these are intended to be
> emergency repair techniques, not something for authors to rely on.


I think any statement that suggests futuristic magic as a potential
technical possibility inside a technical specification and standard is
wrong, and should be avoided.  

JF

Received on Friday, 22 January 2010 02:55:23 UTC