- From: Gez Lemon <gez.lemon@gmail.com>
- Date: Sun, 24 Aug 2008 19:54:30 +0100
- To: "James Graham" <jg307@cam.ac.uk>
- Cc: "Laura Carlson" <laura.lee.carlson@gmail.com>, "HTML WG" <public-html@w3.org>, "Ian Hickson" <ian@hixie.ch>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "Joshue O Connor" <joshue.oconnor@cfit.ie>
2008/8/24 James Graham <jg307@cam.ac.uk>: > I think there is now general agreement that there is more than one way to > skin a cat which I think just leaves one more issue to address here. As I said earlier, even though nested header elements don't feel right, I wouldn't oppose them, as it's better than what the current spec allows. I'll leave the problems of nested headers to the architectural people, as they are better able to explain how they might be problematic than I am. Making the "Budgeted", "Actual", and "Forecasted" cells header cells in the example data table [1] seems strange (assuming the scope algorithm only applies to the cells in the reading order of the table - e.g., left-to-right for English), and there would still be scenarios where the headers attribute should be able to reference a td. > Gez Lemon wrote: >>> >>> In the specific case of table headers, I have reservations about >>> the current spec, but I recognize that it is in a state where the best >>> way >>> to produce improvements is to see how it fares in actual implementations >>> and >>> under user testing. >>> >> >> The improvements in this case have been to introduce conformance >> requirements that mean complex data tables cannot be marked up >> accessibly, which doesn't seem like an improvement to me. >> > > I meant "improvements from the current spec to a better spec". I take it there wasn't a design decision to make the current specification suboptimal with a view to improving it at candidate recommendations stage, as that would be a very strange way of operating. It's already clear that the current specification isn't good enough to be able to provide accessible data tables. >>> People implementing the spec and going "look this user >>> can't understand this type of table because they need more information" >>> is a >>> really strong argument, and really likely to produce a change. In the >>> meantime by not focusing on this issue I hope to free up enough bandwidth >>> for everyone that progress can be made in other areas. >>> >> >> I raised two bugs [1] [2] with that type of information, and both were >> dismissed in minutes, so I haven't seen evidence so support your >> assertion. >> > > The important point was *implementing the spec* to perform user testing. We > agree that there seem to be issues with the current spec. The strongest way > to make the case that these issues need to be addressed is to go away and > implement the current spec and show how it doesn't work e.g. by > demonstrating user confusion compared to a different algorithm in which > headers my themselves have headers. Or to get an implementor to explain why > they won't implement the current spec in their product. If things are removed from a specification that works, why on earth would the implementers need to remove the feature in order to prove it doesn't work, when nothing has been provided to make it work? If the markup language doesn't allow the headers attribute to reference a td, removing those relationships where they exist to adhere to the markup specification will mean information is lost. If the markup language doesn't allow the scope attribute on a td, removing those relationships where they exist to adhere to the markup specification will mean information is lost. Similarly, other accessibility attributes or conformance requirements that are removed from the specification with nothing to replace them doesn't require an implementation to prove that it doesn't work - it's obvious. What's needed is proof that those accessibility attributes or conformance requirements were not necessary. I've not seen proof, but I've seen opinions about how things work that are based on someone's opinion, rather than what actually happens. Your suggestions aren't allowed in the current specification, and dealing with these issues at candidate recommendation stage seems ridiculous, as it's obvious the relationships won't work now. > Of course this isn't the only way to effect change; Hixie might decide that > the arguments presented are stronger than his counter arguments when he next > examines this issue. How does he measure how strong an argument is? He dismissed the counter arguments I provided without understanding them. How come it depends on one person to decide on whether things are allowed in a specification, when it can be proven that those relationships are required? > But it is by far the most compelling and potentially > gets an implementation into the hands of users which is good for them and > good for us when we reach CR. Removing accessibility features isn't good for people who rely on them. [1] http://juicystudio.com/wcag/tables/complexdatatable.html Gez -- _____________________________ Supplement your vitamins http://juicystudio.com
Received on Sunday, 24 August 2008 18:55:07 UTC