[html4all] Figure ideas (was: Article by Catherine: Feedback on accessibility concerns in HTML5)

[zara]

You know, some of this is admittedly over my head but I guess I should add a bit more detail as to the discussion that involved the proposed "figure" element.

We were originally talking about the longdesc attribute and specifically instances where images such as graphs were concerned (as one user felt that longdesc was particularly useful for those kinds of images). I provided an example of a (French) Web site that actually provided longdesc for most of these types of images present on the page (also providing a d-link, most probably for UAs not supporting longdesc ?) :

http://www.3sip.fr/main.php?page=.%2Fstat 

And the discussion then turned to how the "figure" element might support this, where someone provided this type of rough example of how the "figure" element could transmit the relevant information :


<figure>
	<img src="camembert.jpg" alt="Répartition des fournisseurs de tartes Tatins">
	<legend>La tarte Tatin, principaux fournisseurs</legend>
	<table>
		<tr>
		<th scope="col">Compagnie</th>
		<th scope="col">Part de marché</th>
		</tr>
		<tr>
		<td>Boudreau</td>
		<td>40%</td>
(etc)
		</tr>
	</table>
</figure>


And that is basically as far as we got.

While I find this idea very intriguing, I still wonder about some things, notably, about the fact that a lot of Web content is not necessarily built by professionals or by people using sophisticated authoring tools or who know everything an authoring tool could (eventually) do for them but who would be providing this type of information (and whether we like it or not, that is a given in a lot of cases). So, basically, how do we reconcile with the fact that it is hard enough getting people to do longdesc properly and expect them to do something like this. How do we make it easy for them ?

But then, maybe I wonder too much ;)

Anyway, I hope this adds a bit more info as to what was being discussed or speculated upon.

Best regards,


Catherine



--
Catherine Roy

www.catherine-roy.net 




> -----Original Message-----
> From: list-bounces at html4all.org [mailto:list-
> bounces at html4all.org] On Behalf Of Leif Halvard Silli
> Sent: September 20, 2007 7:43 PM
> To: list at html4all.org
> Subject: [html4all] Figure ideas (was: Article by
> Catherine: Feedback on accessibility concerns in
> HTML5)
> 
> On 2007-09-20 16:03:00 +0200 zara <ecrire at catherine-
> roy.net> wrote:
> >  Joshua wrote: [...]
> >> Interesting proposal. Is this along the lines of
> some possible uses
> >> of the <figure> or <object> elements? A closer
> association of the
> >> image and its alternate or long description would
> be a good thing IMO
> 
> > [...] The proposed "figure" element[1] was offered
> as a possible
> > solution because it could be more explicit as to
> its function compared
> > to "object" [...]
> 
> > [...] I wonder however if AT would rapidly support
> something like
> > this. From what I was told during the initial
> discussion, it took a
> > while for JAWS, for example, to support longdesc.
> 
> THe main challenge when it comes to compatibility
> wiht JAWS as well as graphic UAs, seems to be the
> text caption element. Here are some thoughts in that
> regard - which I hope to get some feedback on:
> 
> 	QUESTION:  what is it that makes the
> association between the embedded element of FIGURE
> and the supplied text caption? Is it the very FIGURE
> element? Or is it something with the text caption
> element? I think it is the nature of the FIGURE
> element.
> 
> 	PROPOSAL: To abadon, for semantic and
> compatibility reasons, the proposed LEGEND - and/or
> LABEL and CAPTION as caption text element in FIGURE.
> And instead: The text caption element should be one
> of the following phrase elements: SPAN, ABBR, CODE,
> VAR, SAMP, I, DFN, A  - depending on what is fitting
> in each context. (Or simply say that it should be
> SPAN - with the others as possible content of SPAN.)
> Those element is supported well by all UAs, and could
> also add semantics and useful features to the FIGURE
> element.
> 
> 	SEMANTIC RATIONALE: The draft says that FIGURE
> is a paragraph element - and thus, it is not meant to
> solve the general problem of explicitly associating
> an embedding element and a text caption element - in
> any other way than the natural/implicit «paragraph
> association»: It is a specialised paragraph were only
> embedded content and an associated text is permitted.
> Thus I would maintain that the association is quite
> similar to the association between a DFN element and
> an paragraph - about which the HTML5 draft says:
> 
>         «The paragraph, description list group, or
> section that
>         contains the dfn element contains the
> definition for the term
>         given by the contents of the dfn element.»
> 
> Likewise, one could say that the text caption element
> of a FIGURE element defines the embedded element
> because it is the only allowed textContent element in
> a FIGURE paragraph. As such, it should be simple for
> e.g. JAWS to associate embedding element and text -
> as long as it understands that FIGURE is a paragraph.
> 
> I also don't think it is very fitting nor very
> logical to use LEGEND or LABEL from a semantic point
> of view - since those elements have quite spesific
> uses, quite distant from anything related to embedded
> content.
> 
> 	COMPATIBILITY RATIONALE: Those Catherine
> mentions with regard to JAWS. Those graphic UA issues
> which [Maciej] mentioned in his «Proposal for
> <figure> graceful degradation». The CAPTION element
> could have been a very logical element - it is also a
> an inline content element - and thus would fit well
> inside a paragraph element. However, the
> compatibility issuse speaks against it (not possible
> to style in current IE versions).
> 
> 	FEATURE BENEFITS: HTML 5 draft says that «The
> dfn element enables automatic cross-references».
> Simply put I gather that it works this way: When the
> title attribute of the SPAN, ABBR, CODE, VAR, SAMP or
> I element equals the title attribute of a DFN
> element, then an automatic cross reference is created
> from those elements to the DFN element. Thus, by
> saying that the caption text should be enclosed in
> one of those elements - one could also simply create
> cross refrences to - let's say - long descriptions
> and etc. Thus, letting the caption text be a phrase
> element, would build on that cross-reference feature
> and probably help build support for it.
> 
> 	I also think that not using LABEL, LEGEND,
> CAPTION would simplyfy things for authors - it would
> make it simpler to get that FIGURE is just a
> specialised paragraph element. And it would also
> bring more focus on the purpose of the caption text.
> 
> Please let me know what you think about these ideas.
> 
> [Maciej]: <http://www.w3.org/mid/948E1606-D2BF-4063-
> AD06-4DABFBB67728 at apple.com>
> --
> leif halvard silli
> 
> 
> _______________________________________________
> List_HTML4all.org mailing list
> https://www.html4all.org/wiki
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.487 / Virus Database: 269.13.27/1020 -
> Release Date: 20/09/2007 12:07 PM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.487 / Virus Database: 269.13.27/1020 - Release Date: 20/09/2007 12:07 PM