Re: EO Tutorials review

I agree that AT honours the scope attribute and pays attention to it. It
helps, especially with JAWs 13 and under... I'm fine with requiring it. It
is easy to do. I think the thing I'm trying to address is the simple two
tier heading example with a couple of merged cells on the top row, and not
requiring headers and ids on it. Webmasters want to throw tomatoes whenever
this comes up in training. Well, not THAT bad, but it is a ton of work, and
is prone to error, and surprisingly there have not been many free or cheap
tools that work well and do this automatically... so if the AT can handle
these tables without ids and headers, I think many people will be happy...

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy
policy<http://www.davidmacd.com/disclaimer.html>


On Tue, May 27, 2014 at 10:25 AM, Andrew Kirkpatrick <akirkpat@adobe.com>wrote:

> 2) I think we need to address the issue of a two tier simple table which
> both JAWS and NVDA handle OK now. I think they should be allowed without
> headers and ids. I have an example here
> http://davidmacd.com/test/two-tier-simple-table.html
>
> David,
> I've been looking into this and I'm tossing around a few thoughts around
> tables.  The questions that I think we're trying to address related to H63
> are:
> 1) Is explicit structure required to meet SC 1.3.1 for all-non-simple
> tables?
> 2) Would using scope=row/col be enough?
> 3) Would using headers/id be enough?
> 4) Would using just <TH> be enough?
>
> This quickly gets into the question of accessibility support. I did find
> that your table worked well with NVDA (and assume that your other testing
> is correct), but I had made similar tables and found some issues.
>
> http://awkawk.github.io/scope_col_colgroup.html - this page has five
> tables.  The most interesting ones are the first and last.  The first one
> has only TH elements.  It _almost_ reads correctly - JAWS seems to handle
> it correctly, but NVDA identifies the Massachusetts header as a row header.
>  Voice over trips all over this table in other ways (including identifying
> the "chickens" cell as a header for "massachusetts"??).
>
> The tables where scope is explicitly identified work great.
>
> The final table was made because I sometimes hear that assistive
> technologies don't pay attention to scope, but it is clear that they do.  I
> took a table with scope that was functioning properly and changed the
> attribute values for a few of the scopes and the results are rather
> interesting, but do indicate to me that the AT is using the scope attribute
> to determine table headings.
>
> Then when I tried your test, I get different results, and the only real
> difference is the cells in the upper left - I left mine unmerged and made
> then <td> as they aren't headings, and you have yours merged and made into
> a <th>.  So there's something in the AT's heuristic for determining what is
> a heading and what is not that is choking on this change.
>
> The conclusion that I'm coming to is that if one wants to have a
> significantly higher degree of certainty that AT will read the table
> correctly that they need to have the scope="row/col" or headers/id
> explicitly indicated for all of the headings.
>
> What do you think?
>
> AWK
>