Techniques issues for Guideline 2.4
Here is an overview of issues around techniques for Guideline 2.4. In some cases there are proposals too although strictly speaking I'm not supposed to do that until next week.
HTML Techniques
Test Case 184
- Test case refers to presence of a link to a site map from a particular page but does not show a good vs. bad site map.
- I think this is a good technique. I don't think it's properly mapped to Level 3 Success Criterion 1 which is about reading order. It maps better to Level 2 Success Criterion 2 because of multiple means of navigation, or Level 1 Success Criterion 1 because of programmatically determined relationships. However, that Success Criterion refers to relationships within the content (and presumably delivery unit), and the technique refers to relationships between delivery units.
- Issue 655 asks when this technique needs to be applied: "Is this only necessary when the document already contains a formal structure like previous/next chapters in a book?"
Test case 147
- The only passing test case is a link rel=index. I'd like to see other ones, particular next and previous. To make the test cases really valid we'd need to have the targets exist.
- I think the technique is ok and properly mapped to Level 3 Success Criterion 1. However that Success Criterion is in major flux.
- The comment about using CSS should be a separate technique.
- There are suggestions about how to evaluate this which belongs elsewhere.
- Although this technique is in a section about layout tables, I think if we expect techniques to be mixed into other document it could lose context. We should put some of that information into the technique itself.
- This technique is very long for a technology-specific technique. Partly because of the issues above.
- Do we concern ourselves with linearization of data tables? I would say no but some of the wording in the technique might suggest yes.
- Issue 248 discusses supporting automated differentiation of data from layout tables. I'm not really behind that whole issue but it affects this technique.
- Issue 1117 wants us to be more clear about whether it's ok to use layout tables. I guess we're a bit wishy-washy on that. Issue 1189 says we need to keep them for a while.
Test case 133
- I don't think these test cases are valid for this requirement. The test cases simply show data and layout tables. We actually need to presume it's a layout table, then show one that linearizes well and one that doesn't.
- The guideline talks about "repeated material" though it doesn't define that clearly. But the technique talks about "logical sets" which could mean it has a different scope.
- This technique suggests methods for identifying and labeling groups of links, but they rely on conventions rather than specified behaviours of HTML features.
- Per the editorial note, part of the technique actually talks about why it's better to provide text links than graphical links. That should get moved somewhere else.
- I don't think the MAP element should be suggested. Although the HTML spec for MAP permits block-level content inside a MAP element, this is expressly for the purpose of making image map markup more accessible or useful. I do not believe it is intended to be a mechanism to group links that are not associated with an image map.
- Issue 246 presents examples intended to help us provide additional techniques.
Test case 155
- We need to complete this test case.
Test case 156
- We need to complete this test case.
Test case 157
- We need to complete this test case.
- The technique is not clear whether it's saying "do this" or "don't do this". The label "future" suggests we might want it done in the perfect world baseline, but the editorial note says this needs to be a negative technique.
- As in Issue 995: I think tabindex as a means to skip link groups is not something we should recommend. Tabindex can be useful if the source code order of elements creates an undesirable tab order. But using it to skip link groups means those links are always at the end of the tab order. Sometimes you do want them at the beginning of the tab order though. It's better to rely on techniques to group links and skip link groups than use tabindex to push things around.
Test case: none provided. We will need to do so if we keep the technique, but I think we shouldn't.
- There's language about "probably" and "definitely" that we should make more testable.
- The example shows a <map> element. Per my comments above, I think we should find a better example.
- The ednote refers to issue 241 that is now closed. We should remove the ednote.
- Issue 1119 proposes we retitle this to say "skipping repetitive links".
Test case 28
- There is a test description but not test files. Need to provide.
- The task talks about hiding navigation links, but the description talks about hiding the skip link. Need to clarify, probably in favour of hiding the skip link.
- This success criterion maps to Level 2 Success Criterion 3. However, it's not a means to comply with that Success Criterion , it's a means to feel less bad about having to comply with that. I don't know if that is the best approach. At least this technique should be clearly marked as optional. But I can't think of any guideline this maps to. All I can think of, if we want to keep techniques like this and want to map them to guidelines, is to create a new guideline along the lines of "take appropriate measures to give yourself less heartburn about following WCAG, rather than not following WCAG". I'm being facetious but that really is the only solution I can think of to the problem.
- Even with the above concern, I'm not sure this technique is useful. It removes benefit of providing skip navigation link for some users.
- The comment about "do not hide the link with the display property" seems worthy of its own technique, since it's a recommendation of what not to do while the rest is a recommendation of what to do. That is, if we keep this class of technique at all.
Test case 158
- Empty test case, to complete if we keep the technique.
Test case: no test cases defined. Create if we keep the technique.
- The statement about avoiding ASCII art belongs in a technique for another guideline.
- Level 2 Success Criterion 3 refers to skipping repeated information. That is theoretically not usually the case with ASCII art so the guideline is not applicable. If we want to keep this technique we need a new Success Criterion , perhaps under 2.4, to skip unwanted information.
Test case 83
- This applies to the 1.1-ish aspect of the technique so should be moved along with that aspect of the technique.
- Test files need to be created to show ASCII art, and an image instead of ASCII art.
Test case 84
- Instructions borrowed from test 83 above. Need to be corrected to be applicable to skipover link, not substituting with an image.
- Test files need to be created to show ASCII art with and without skipover link. Pretty much what's in the example of the technique.
- This is not tied to a Success Criterion, just to Guideline 2.4. We need to create a Level 2 Success Criterion for this. Yvette's proposal asks about that and the answer is YES!
- There is a comment about difference between the title attribute and the title element. That should probably exist also in the title element technique.
- The text "...to describe the contents of each frame..." bothers me because it's longdesc-like. The second sentence describes the labeling feature, which is sufficient.
- Issue 1107 requests clarification because the comment about the difference between title attribute and title element seem confusion.
Test case 31
- Mapping to guideline is wrong. Should be same as technique.
- Test files should include more than one frame to avoid confusion, since it's not really meaningful / necessary to title a frame if there's only one.
- Pass instructions should refer to the following test, not "any test".
Test case 32
- Mapping to guideline is wrong. Should be same as technique.
- Same comment as previous test case, there should be more than one frame in the tests to avoid confusion.
- The title for the fail test case is not obviously and egregiously bad enough to be sure we understand the intent. Change it to something like "frame1".
- This should at best be considered optional, but perhaps can be removed.
- If kept, doesn't map to a Success Criterion , same as above.
Test case: none provided. Need to create if we keep the technique.
- Need to be sure it's clear we're saying, this is a technique we don't recommend.
Test case 34
- Test case describes positive application of longdesc, while we're saying "don't do it". Test case should reflect that.
- Test case refers to longdesc on the frameset, not on the frame elements. While that makes more sense to me, that's not the way HTML specs it and that's why we're deprecating the technique. The test case instructions and test files would need to be updated should we keep the technique.
- I think this maps better to Level 2 Success Criterion 2 than Level 2 Success Criterion 1.
- There is no description, just ednotes. Need to create.
- Ednote 1 refers to accesskey. I think that is a different technique from this one and should be dealt with in Keyboard Access or in a new technique. The reference to accesskey spec should also go.
- Ednote 1 talks about "tabspaces", i.e., links and form controls existing in different tabspaces. I'm reasonably sure that isn't true but we need to resolve that and address if appropriate.
- Issue 296 questions the use of tabindex at all. Need to resolve. Ednote 2 reflects that a bit. Particularly for form controls, why in heck would you design a form so badly you need to use tabindex?
- Issue 1126 points out the task refers to all tabable items while the title refers just to form controls. We need to deal with that.
Test case: none provided. Need to provide examples of use of tabindex and not, as well as one in which tabindex is provided on some controls but not all.
- The ednote says we're unsure whether to keep this technique, but we have to say something because it's a WCAG 1.0 requirement.
- This only maps to guideline 2.4, not to a Success Criterion . We would need to create a Success Criterion if we decide to keep it, though not sure if we keep it as a deprecated technique.
Test case: none provided. Need to provide if we keep technique.
- The ednote says this is mapped to 2.4 because in practice it relates to successful linearization. But this is a technology support issue and maps to 4.2 or whatever became of that.
- The ednote also points out this is a baseline issue. Probably we don't need the technique, because if CSS is not in your baseline you're making sure it makes sense without CSS, and if CSS is in your baseline you don't care about this. Therefore this probably can disappear.
Test case: none provided.
Missing / Proposed Techniques
Here are issues I see for the Success Criteria from a techniques perspective, beyond what was covered in existing techniques above.
- The problem with this guideline is that techniques for it are essentially a tutorial in structural markup. There are structural things we like to see, such as headings, lists, tables, etc. but we've questioned whether we want to repeat the HTML spec in our techniques. We can select structural elements we really care about but sometimes the line between a real benefit to accessibility and a good general practice is blurry.
- That said, I think many of the data table techniques might belong here. Caption and summary might be under label guidelines but headers, scope, headers / id markup, row groups, and column groups sound pretty much like programmatic determination of structure.
- If we do that with data tables, using them would map to a level 1 Success Criterion , so the technique against ASCII art tables would be superceded, which currently maps to a 4.2 Level 3 Success Criterion . Probably I would remap that technique as well to this Success Criterion , so it becomes Level 1 as well.
- There are a lot of other techniques about structural markup mapped to 1.3 that I think I want to absorb (sorry Becky). For data tables the argument is clear because the structural markup is about identifying the relationships between rows and their headers. The other ones have a blurrier line and I think we have to think very carefully for a given technique whether we recommend it to separate content from presentation or whether we recommend it to identify relationships. We might want to clarify the distinction in the guidelines somehow. Yvette's proposal gets at this issue and, given all I say above, I lean towards clarifying the distinction between 2.4 and 1.3 rather than zapping one in favour of the other.
- I don't believe any CSS techniques will relate to this Success Criterion .
- I also don't believe Script techniques will relate to this Success Criterion , although script usages may affect structure and relationships. In particular if scripts modify the DOM they should be writing good structure, but that's another case of calling out every potential usage. Perhaps it's at the General Techniques level that we say "make sure you always mark up your structure properly. That said, Becky mapped a lot of her proposed techniques to this Guideline.
- No need for HTML techniques unless we want to document how to do internal bookmark links. For the most part this seems like a General technique.
- No CSS techniques.
- Script can be used to do this. I believe Becky proposed use of the <link> element and script to expose it (ok, that's a combination HTML and script technique). It would also be possible to have a script generate a TOC off the headings if they're properly marked up, though why you'd do that I don't know since you could have your active server do the same thing and have static HTML. That could be a user agent plugin of course, which sounds like a nifty idea (question is how it would know where in the page to insert the TOC). But if this can be done by a U A plugin, is this in the U A domain rather than the authoring domain? I'm working myself to questioning this Success Criterion when considering techniques.
- For the most part I think this is a general technique, unless we want to document how to create search forms in HTML. The <link> element seems to fit here well.
- I don't see any CSS or Script techniques.
- I think we're pretty well covered for HTML techniques. Yvette's proposal asks whether we need a separate Success Criterion for skipping link groups but I agree with the consensus that we can handle that in techniques in the way we are doing. That is, if you technology allows you to skip groups easily, fine, otherwise provide explicit links. We'll have to indicate the baseline info for those techniques then.
- It might be possible to propose script techniques but they'd rely on some kind of HTML structure so I'm not sure it would be useful.
- HTML Layout tables seems to be the main issue here. Above I proposed moving tab order in forms to the following Success Criterion .
- We might want to add a technique about the order of form controls, although to some extent that's a subclass of layout tables.
- Perhaps CSS fallback is relevant here. I thought we had a technique for that but can't find it, maybe we need to create as it's a WCAG 1.0 issue.
- Again, no CSS or Script.
- Yvette's proposal indicates we don't know whether to promote or delete this Success Criterion . I guess since it's possible to provide techniques and they seem somewhat useful I would lean towards keeping this.
- We're missing the obvious HTML technique about tabindex for links. Otherwise I think we're covered with the proposals above.
- Again, with Script you can support or violate this Success Criterion but I think that's more something for general techniques. I can't think of any script features that directly address this.
- I thought we were considering removing this though Yvette's proposal is to clarify the examples. But I don't think this affects HTML, CSS, or Script.
- The HTML technique on MathML instead of images might be related to this though it is mapped to other success criteria. If we do keep this success criterion, I would consider co-opting that technique here. However, that isn't strictly an HTML technique.
- I don't see any techniques beyond TITLE in HTML.
- This Success Criterion is in flux. I propose removing it as it seems redundant with Level 1 Success Criterion 1, as John pointed out. However, if we keep it we need an HTML technique for the P element. But then we might as well just document the entire HTML spec.
- Hmm... Are header tags relevant to this? I don't think so since they're not part of hierarchical markup, yet that seems close to the intent?
- We could document things like nesting DIV elements and using the "title" attribute. But I'm unsure of the accessibility benefits, in today's technology. Would that be in conjunction with header elements? In future technology maybe it's a good idea if DIVs were collapsible or something but HTML isn't that specific about the intended use of DIV. I can't think of any feature that really is.
- This can also be done with nested layout tables. But yuck! And again, I question the benefit.
- I see the value of this Success Criterion but I gotta say, I'm not sure HTML, CSS, or Script are appropriate technologies to implement it. Which means you can't conform to WCAG at level 3 in any of those technologies, unless we fudge it in HTML as suggested above with DIVs. XmlSpec, the XML language we're using behind the scenes for our documents, does support this and we make good use of it.