Tutorials/Feedback/EO2014-06-06
WCAG WG Feedback
Tables organization
An issue that came up in the last weeks and also with the WCAG WG feedback is the simple tables. We found out that we need scope on some of the tables there. Additionally the first example on the irregular tables tutorial is conceptually a simple table but needs elaborate markup to make it accessible.
- Should we restructure the sections, and if we do, what can we do to make clear what to expect in which section? {Eric, 2014-Jun-05}
- I am not sure what you mean about conceptually a simple table since we have determined that tables that require more than are NOT simple tables by the very definition we use within the tutorial construct. What am I misunderstanding? {Sharron, 2014-Jun-05}
- By elaborate markup on the first irregular table do you mean the "scope" attribute that's already there. If so it doesn't seem particularly elaborate. I wouldn't see a need to change the location of the first irregular example. Similarly, I don't think requiring a "scope" attribute disqualifies the "simple tables" from being listed in the "simple" section.{Howard, 2014-Jun-05}
- One thing I don't like - and this may fall outside the topic of organization - are the listing of "complex: irregular" & "complex: multilevel" in the navigation menu. I'd rather see either a header of "complex tables" (this may be difficult on a menu) above the "irregular" & "multilevel" menu items or simply leave out the "complex" in front of those 2 menu items. Especially with the wrapping of those 2 menu items it makes it visually confusing.{Howard, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
Groups of images, ARIA example
We're not sure that the grouping example for images with role="group" is quite ready. Neither JAWS nor NVDA reads this as I'd hope. JAWS makes mistakes and NVDA ignores the grouping as far as I can tell. Is this ready to advocate for people to use? For that matter, what benefit are we expecting from grouping this way? It seems that it is going to be difficult for users to remember what level of the grouping they are in for an example like this one.
- As was noted by some in the EO comments, we could/should probably add compatibility information. {Eric, 2014-Jun-05}
- I agree that this deserves a compatibility note. I think the WCAG-WG comments were based only on using JAWS in Firefox though. Using Internet Explorer, this grouping technique works extremely well, The group as a whole is read aloud , almost as though it were a single paragraph. It all made sense. The Firefox rendering exposed the start and end of each group and duplicated the <figcaption> content, which was tedious and unpleasant. NVDA doesn't attempt any grouping in either browser, but it's not great at grouping under several situations. {Bim, 2014-Jun-05}
- Agree with need for compatibility note. Also need to consider Wayne's comments from last week about the need to be more rigorous in holding AT and browser makers accountable for supporting accessibility. Should we file a bug report? Bim's experince in IE seems to answer the final question in the original comment about "waht benefit is expected." {Sharron, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
ARIA
… in HTML4
Loretta: Approach 3 states that the technique is only valid for HTML5. I thought ARIA could be used with HTML4. AWK: I think that this is a bit confusing also, but think that they mean that the HTML4 DTD doesn't allow it and HTML5 does. Of course, to meet WCAG you don't need to have fully valid code... Should be clarified to indicate the reality of using ARIA in HTML4.
- Agree with AWK. Suggest modify the phrase to say "The technique used in this approach is fully valid only in HTML5. While it may be used and will render in HTML4, its use will prevent code validation. In that sense, this WAI-ARIA feature may not yet be as widely supported ... {Sharron, 2014-Jun-05}
- +1 to Sharron's solution {Howard, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
… in General
We were surprised by the general lack of mention of ARIA attributes (and that the relevant ARIA techniques are not listed). I assumed this is because the tutorial is being conservative, and EO feels that ARIA is not sufficiently accessibility supported. But then the Images of Text page recommends using MathML. Is MathML better accessibility supported than ARIA? Similarly, is CSS3 (also from that page) more accessibility supported than ARIA? Or am I misreading the reasons that ARIA isn't mentioned in the rest of the tutorial (except for role=presentation, which is called out as a less desirable alternative to alt="", and several examples for complex images)
- Good point and I, too would like to see more mention made of WAI-ARIA. I know there is a common (and somewhat justified) fear of developers thinking that if they have an accessibility barrier they can just throw ARIA at it. Still it seems that there are cases where ARIA is a reasonable solution worth mentioning and that we could take greater advantage of this arena to make the case for rational use of the technology. {Sharron, 2014-Jun-05}
- Isn't the assumption that these tutorials will be expanded upon? Can WAI-ARIA be added later? And I'm not sure the complaint is that there needs to be a WAI-ARIA section or that WAI-ARIA is not mentioned as a solution within the sections that are already present.{Howard, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
ImageMap
The note can be removed because it isn't an issue that affects WCAG conformance - the ability of image maps to work for any user on a mobile device is what this note is talking about and it isn't specifically related to accessibility.
- Should we include non-accessibility related notes like this or do we consider this important for mobile accessibility? Do we need to rephrase? {Eric, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
Summary
WCAG WG mentioned that we probably shouldn’t give the HTML4 summary attribute such center stage (on the caption/summary page and concentrate more on the new HTML5 solutions (which are ARIA solutions). Discuss.
- Seems like a good point. Summary is deprecated, is it not - so it may not be supported in future browsers. I think it's okay to mention the technique but, as suggested, perhaps give it less prominence.{Howard, 2014-Jun-05}
- Comment {Name, 2014-Jun-XX}
EO Comments
Cognitive load
Andrew had a few notes to mention the “cognitive load”, for example splitting complex tables maxes it easier for more people than just screen reader users to digest information. Andrew’s Comments:
On Images -> Tips:
Suggestion: consider adding a tip that 'alt' is primarily for screen reader users and those choosing not to display images, however as image complexity increases, cognitive load also increases and visible explanations of images are desirable.
On Tables -> Multi-Level:
Location: example 3 (Split up Multi-Level tables)
Suggestion: consider adding a note re cognitive load being easier for this solution
Rationale: it's true for all people not just screen reader users and/or those with cognitive impairments
- Probably we should get feedback from the Cognitive A11Y TF on that issue and bring it into a later version. {Eric, 2014-Jun-05}
- I'm not sure we need their input? Depending on the specific suggestions, it seems we might be able to handle it. :) {Shawn}
Mention text-only?
Shadi: “Consider an FAQ [in the images tutorial]: "I've been told text-only pages without images are more accessible" (may need to be discussed with EOWG if this is a good or bad idea).”
- If we decide to do something like this, suggest different wording, e.g., "Should we provide a text-only version without images?" or such that does less to perpetuate the myth by itself. (also note it will take a little effort to craft a good, succinct answer) {Shawn, 2014-Jun-06}