- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Mon, 15 Aug 2011 13:34:35 -0700
- To: Detlev Fischer <fischer@dias.de>
- Cc: w3c-wai-gl@w3.org
- Message-ID: <CAHu5OWburcYA65d5TDhrn87NOdgfzDOrm0LAB9UcE+T31jW5gw@mail.gmail.com>
On Mon, Aug 15, 2011 at 5:42 AM, Detlev Fischer <fischer@dias.de> wrote: > Hi, > sorry to enter this discussion at such a late stage. > > I think that all examples in all techniques implicitly encourage design > patterns. They are read as 'best practice'. Clearly, this layout should have > been created using CSS, not with a layout table 'repaired' with tabindex. > While we particularly want to document best practice techniques, we often include examples or techniques that are not necessarily best practice, but are still sufficient to meet the success criterion. This is to help people understand the meaning of the success criterion. It is better to cast some light on the grey areas. > > That's why I feel uneasy about having such an example in a sufficient, even > in an advisory, technique. The use of layout tables is actively discouraged > elsewhere in WCAG (I believe). While their use does not violate any SC when > the linear reading order is meaningful, I personally think the bride and > groom example is possibly in violation of SC 1.3.2. In any case, the example > is not 'best practice'. It actively introduces a problem that the use of > tabindex in H4 is then supposed to repair. > I don't understand why you think the bride and groom example is not a data table. Or why you think it might violate SC 1.3.2. > > On another note, I think it is highly relevant to cover the rather frequent > use of scripted tabindex for managing the focus order in lightboxes used as > modal dialogues. While there are many a11y issues with lightboxes, they are > everywhere and unlikely to go away. In our testing experience, they > frequently introduce grave problems for keyboard users since authors fail to > manage focus order properly (and fail to move focus back to the trigger when > the lightbox is closed). > > What's there in the techniques to deal with lightboxes? SCR21 and SCR26 > deal with insertions that are meaningful content in the normal reading > order. This leaves us with SCR37; but unlike the sorting example in SCR37, > modal lightboxes often are not a meaningful part of pages' reading order: > that's why they are generated and removed on the fly, meaning that SC 1.3.2 > would be OK on the default page. > By no means do we have an exhaustive set of scripting techniques. Additional submissions would be very welcome. One challenge we have had in the past is that most working scripting examples are complex and potentially cover a large set of success criteria. We have wrestled with how to include such examples most effectively within the WCAG framework. > One could argue that F85 (Failure of Success Criterion 2.4.3 due to using > dialogs or menus that are not adjacent to their trigger control in the > sequential navigation order) rules out this pattern anyway. But I think it > makes a difference whether content clearly makes sense in the sequential > navigation order or not. F85 should only reply to the former. > > A case in point may be glossary entries. Arguably, inserting them into an > inline text at the point where they are called up disrupts the integrity of > content and is worse then having such entries inserted dynamically at the > end of the source code, displayed in a lightbox, and put into the the focus > order via JS/tabindex. > > In practical terms, many common JS frameworks place modal lightboxes at the > beginning or end of the source code - sometimes, as we have seen, for a good > reason. Currenly, I believe there are no examples in SCR techniques dealing > with this frequent pattern. Managing tabindex of modal dialogues with > scripts (and possibly having alternative renderings of lightbox content if > JS is inactive) may be an option for a further SCR-Technique. It might also > need a qualification of F85 to exclude dynamically generated content that is > better presented outside the sequential reading order. > > For H4, maybe there are examples where reading order is clearly OK both > ways? In which case I agree with Adam Solomon that H4 looks more like an > advisory technique or might be dropped altogether. A difficult one... > > Regards, > Detlev > > Am 15.08.2011 08:44, schrieb Loretta Guarino Reid: > >> >> >> On Sun, Aug 14, 2011 at 11:16 PM, adam solomon <adam.solomon2@gmail.com >> <mailto:adam.solomon2@gmail.**com <adam.solomon2@gmail.com>>> wrote: >> >> Basically the principle is the same, just that html5 applies >> tabindex to be global (not just focusable form elements), AND lets >> us declare a value of -1. So we might have some useful examples for >> these two differences that we would not have in html4. >> >> >> This does open up lots of possibilities. This should be an interesting >> discussion. >> >> >> >> On Mon, Aug 15, 2011 at 9:11 AM, Loretta Guarino Reid >> <lorettaguarino@google.com <mailto:lorettaguarino@google.**com<lorettaguarino@google.com>>> >> wrote: >> >> I think you are saying that because the default tab order would >> conform to WCAG, there is no need for a technique that changes >> the tab order. >> >> But changing the tab order is permissible under WCAG as long as >> the resulting order "makes sense". And if the author thinks that >> changing the tab order improves the usability, we want to make >> it clear that this still conforms. So although the author did >> not need to change the tab order in any of the H4 examples, >> changing it in these ways does not violate WCAG. >> >> Is there something different about tabindex in HTML5? If not, we >> may not need an additional technique. We may just need to see >> whether H4 applies to HTML5, as well, or can be modified so that >> it is clear that it also applies to HTML5. >> >> >> On Sun, Aug 14, 2011 at 11:03 PM, adam solomon >> <adam.solomon2@gmail.com <mailto:adam.solomon2@gmail.**com<adam.solomon2@gmail.com>>> >> wrote: >> >> I guess I am just missing something. I still feel that >> sufficient techniques, though not being the only option for >> satisfying a success criterion, do in fact come to correct >> some deficiency in the web page. Sure, there are other ways >> to do it, but the deficiency needs to be addressed one way >> or the other. In H4, there is no deficiency by WCAG >> standards. Since the reading order is acceptable (if it >> weren't, we couldn't use this technique anyway since it >> violates 1.3.2), the focus order must also be acceptable by >> definition, and the added benefit of reading one person at a >> time in the bride/groom example adds no WCAG success to the >> web page, and addresses no WCAG deficiency. >> If you all still think that this is a valid technique, then >> I will draft the html5 technique in accordance with this >> one, and hopefully have it ready for this week's meeting. >> >> >> >> On Mon, Aug 15, 2011 at 8:51 AM, Loretta Guarino Reid >> <lorettaguarino@google.com >> <mailto:lorettaguarino@google.**com<lorettaguarino@google.com>>> >> wrote: >> >> Adam, I am still having trouble understanding why you >> think the inclusion of the HTML tabindex technique is a >> problem. >> >> I think you are claiming that it is unnecessary? That it >> is always possible to use a different technique to >> satisfy the success criterion? Am I understanding that >> correctly? >> >> Loretta >> >> >> >> On Sun, Aug 14, 2011 at 10:46 PM, adam solomon >> <adam.solomon2@gmail.com >> <mailto:adam.solomon2@gmail.**com<adam.solomon2@gmail.com>>> >> wrote: >> >> Sailesh, >> If one would expect to fill out the form one person >> at a time, would the default table layout (not >> taking into consideration focus order) not violate >> 1.3.2? After all, the programmatically determined >> reading order would read the cells of the table row >> by row, not person by person. If so, then this is >> not a sufficient technique. >> We must then conclude that there is no violation of >> 1.3.2, and the author's tabindexing is only a >> preference, in which a case this technique is >> totally irrelevant. >> Either way, there is a problem. >> >> On Mon, Aug 15, 2011 at 6:07 AM, Loretta Guarino >> Reid <lorettaguarino@google.com >> <mailto:lorettaguarino@google.**com<lorettaguarino@google.com>>> >> wrote: >> >> >> >> On Sun, Aug 14, 2011 at 8:03 PM, Sailesh >> Panchang <spanchang02@yahoo.com >> <mailto:spanchang02@yahoo.com>**> wrote: >> >> Loretta, >> In principle, if you content: >> >But the use of H4 is not required for SC >> 2.4.3... >> Then why is it listed as a sufficient >> technique? >> >> >> Because it is sufficient. You may use it, but >> you may use some other sufficient technique. >> >> Adam, >> Well in that example of groom and bride, >> without tabindex, one may content that >> reading order is meaningful. But if one >> navigates across fields row-wise, it does >> affect meaning or operation. As I said in my >> last email, the intent is not to compare >> first names but actually enter data into a >> form. I imagine most would want to be done >> with data for one person then input data >> for the next. While filling out paper forms >> too,I'd complete the form for person#1 and >> then person#2 and not fill out first name >> for person#1 then jump to form for the other >> chap and fill out his first name. That is >> not logical. On a Web page the fields may be >> placed next to each other visually but they >> are meant to be navigated "logically" for >> person#1 and then #2. It is not the author's >> choice or reading order... the author is >> constrained by layout / design and must use >> tabindex (h4) to ensure navigation does not >> affect operation. >> Sailesh >> >> >> >> >> >> >> >> >> >> > > -- > ------------------------------**------------------------------**--- > Detlev Fischer PhD > DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen > Geschäftsführung: Thomas Lilienthal, Michael Zapp > > Telefon: +49-40-43 18 75-25 > Mobile: +49-157 7-170 73 84 > Fax: +49-40-43 18 75-19 > E-Mail: fischer@dias.de > > Anschrift: Schulterblatt 36, D-20357 Hamburg > Amtsgericht Hamburg HRB 58 167 > Geschäftsführer: Thomas Lilienthal, Michael Zapp > ------------------------------**------------------------------**--- > >
Received on Monday, 15 August 2011 20:35:11 UTC