- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Tue, 27 Jan 2009 17:32:07 +0100
- To: "TSDTF" <public-wai-ert-tsdtf@w3.org>
Hi Carlos, All, Below are responses to all of the issues, based on the discussion during the telecon. At 02:11 27/01/2009, Carlos Iglesias wrote: > > >01 - There are concerns about the effectiveness of the test samples > > >(the use of a blockquote is not obvious) > > >02 - Concerns about quote visibility (quotes not visible in IE) > > >03 - The related technique (F2) has been changed, but still doesn't > > >relate to the test sample > > >04 - Concerns about quote visibility (quotes not visible in IE) > > > > My understanding of the status of test samples > > content-structure-separation-programmatic_001 > > through 004 was that I made edits, reported at > > > <http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2008Oct/0006.html>, > > to address earlier issues, > > and that we later needed to check if the technique references > > were still OK after CR publication. > > Tim did this for these samples and also wrote that my earlier > > edits seemed fine: > > > <http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2008Nov/0014.html>. > > >Still think that F2 is not applicable to 03 because no there is not >change in the appearance of text that conveys meaning without using >appropriate semantic markup (I think that in this test sample is rather >the other way around) What 003 wants to illustrate is the use of a Q element for something that is not a quote but only for the visual rendering of the Q element, which is not consistent across browsers. The current test file, <http://www.w3.org/WAI/ER/tests/xhtml/testfiles/content-structure-separation-programmatic_003.html> should display the Q element italicized. Internet Explorer 6, Opera 9, SeaMonkey 1.1, Firefox 2.0, Firefox 1.5 and Firefox 3.0 display the Q element as normal text (i.e. not italicized, bold, or in a different colour. Except for Internet Explorer 6, all these browsers display quote marks by default. The addition of a style attribute to the Q element makes sure that all the above browsers, including IE6, change the appearance of the Q element. So we have a test file where CSS is used to emphasize a phrase visuaally without conveying that emphasis semantically, as in failure example 3 in <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F2>. So why would F2 not apply to this test sample? >Nothing to say about the rest of test samples if Tim has previously >agreed with the changes OK, thanks. > > >16 - OK > > >18 - OK > > >19 - OK > > >26 - There are no changes to this test sample. > > >The issues raised in the CR are still applicable > > > > The metadata were modified (more precise title, description > > and purpose), but not the sample file. > > I assume you are proposing to change this from a pass to a > > fail based on your argument that summary attributes on layout > > tables are not prohibited. > > However, there is a failure F46 (referenced by the metadata): > > "Failure of Success Criterion > > 1.3.1 due to using th elements, caption elements, or > > non-empty summary attributes in layout tables" > > <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F46.html> > >Extract from F46: "Empty summary attributes are acceptable on layout >tables, but not recommended." Indeed, *empty* summary attributes on layout tables don't cause a failure, but the summary attribute in 026 was never empty (I checked CVS history). Please check the source code of <http://www.w3.org/WAI/ER/tests/xhtml/testfiles/content-structure-separation-programmatic_026.html>. If you think that F46 still does not apply, can you please explain why. > > >30 - Issues raised in the CR has not been addressed > > > > I propose the following change to address the issue: > > - add a column for the courses for which the students have > > enrolled (more "realistic" table), > > - change the summary to: "This table list students with their > > student ID and the course for which they have enrolled. > > Students are listed alphabetically by family name." This change was accepted in today's teleconference; the test file has been modified accordingly. > > >36 - One file don't follow the naming > > >conventions (not sure what the comment about the form > > submission means) > > > > We have a number of test samples with forms that may be > > submitted but where we don't want users to land on an "Error > > 404", so we have dummy pages where the form submission > > "lands" and that aren't really part of the test case. > >Not sure if they can be considered part of the test case or not, but >anyway think they should follow the same naming conventions This was discussed during the telecon. The xxx_processformdummy.html files have been renamed to conform to the naming convention. > > Where > > did you find that comment? > >SR (Checks for test files) The form submission issue has been fixed. There is now a dummy submission page that conforms to the naming convention. > > > > >37 - OK > > >41 - There are no changes to this test sample. > > >The issues raised in the SR are still applicable > > > > See comment on 036. To conform to the naming convention, all > > files ending on "_processformdummy.html" need to be renamed. Done. (Cf. supra.) Best regards, Christophe > > >Regards, > > CI. -- Christophe Strobbe K.U.Leuven - Dept. of Electrical Engineering - SCD Research Group on Document Architectures Kasteelpark Arenberg 10 bus 2442 B-3001 Leuven-Heverlee BELGIUM tel: +32 16 32 85 51 http://www.docarch.be/ --- Please don't invite me to LinkedIn, Facebook, Quechup or other "social networks". You may have agreed to their "privacy policy", but I haven't. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Tuesday, 27 January 2009 16:32:51 UTC