Re: Failures for SC 2.4.4

Hi Loretta,

I've just read through the Wiki examples, and the table example does
make sense. I just couldn't imagine how it would be helpful, but I can
see it makes sense with the example.

On a separate note, I think the markup in the samples needs improving,
and it would also help with credibility. In particular, it's very bad
to have empty th elements (it should be a td), and I don't think I've
ever encountered </img> outside of WCAG techniques.

Regards,

Gez

On 02/10/06, Loretta Guarino Reid <lguarino@adobe.com> wrote:
> Gez, you may want to look at the current wiki pages for SC 2.4.4, which
> includes a common failure as well as examples of meeting SC 2.4.4 using
> tables, lists, and paragraphs. See whether you agree with the proposed
> examples.
>
> http://trace.wisc.edu/wcag_wiki/index.php?title=How_to_Meet_Success_Criterio
> n_2.4.4
>
> Loretta
>
>
> On 10/1/06 12:32 PM, "Gez Lemon" <gez.lemon@gmail.com> wrote:
>
> >
> > Hi Loretta,
> >
> > On 01/10/06, Loretta Guarino Reid <lguarino@adobe.com> wrote:
> >>
> >> To determine whether SC 2.4.4 provides accessibility guidance, we need to
> >> determine what uses failure 2.4.4.
> >
> > I'm not sure what you mean by failure 2.4.4. In the how to meet for
> > this success criterion, there are no failures. Should we create some?
> >
> >> Looking at web sites raised the following
> >> questions for me:
> >>
> >> 1. Should the use of a table cell for context only apply to data tables, and
> >> not to layout tables? Can we write the technique in a way that makes this
> >> clear?
> >
> > A layout table has no structural elements (other than table, tr, td)
> > or structural attributes, so it would be impossible to provide context
> > for a layout table. For a data table, I'm not sure that the context
> > would provide enough information. For example, if you have a data
> > table where one of the columns contained links to a company, but they
> > all user the same link phrase, "Details", where would the context be
> > provided? The header details wouldn't provide sufficient context for a
> > particular cell, as the header would apply to all columns or rows
> > (depending on its scope). It would be possible to provide a complex
> > relationship between individual cells, but data table are very rarely
> > marked up with that amount of detail:
> >
> > <td id="c3">XYZ Consultancies</td>
> >
> > -----
> >
> > <td headers="c3">
> >     <a href="company.php?id=3">Details</a>
> > </td>
> >
> > In above example, the last cell is programmatically associated with
> > the cell whose id is c3, so the context for Details could be evaluated
> > as being for "XYZ Consultancies"; is that the kind of relationship
> > you're referring to? Although this relationship works, it's a very
> > rare scenario, as headers tend only to be used on tables with a
> > complex relationship that have more than one logical header. It's more
> > likely that the association between a cell and its header in a data
> > table would apply to more than one cell, which would result in
> > ambiguity when relying on the data table alone for context.
> >
> >> 2. When a paragraph, list item, or table cell is used for context, how much
> >> mark-up can there be between the link and the context-providing element? For
> >> instance, if a paragraph contains a list or table, and the list or table
> >> contains a link, should it be possible to use the "enclosing paragraph" as
> >> the context for the link?
> >
> > A paragraph couldn't contain a list or a table. In terms of defining
> > relationships that could allow programmatic association, I would leave
> > it that inline elements get their context from their immediate parent.
> > For example, a link in a table cell could get its association from
> > sibling elements and/or text in the table cell, but expecting the
> > context to be provided at a higher level isn't reasonable (in my
> > opinion).
> >
> > Regards,
> >
> > Gez
> >
>
>


-- 
_____________________________
Supplement your vitamins
http://juicystudio.com

Received on Monday, 2 October 2006 16:55:59 UTC