This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Review of html4 to html5

From WCAG WG
Jump to: navigation, search

Originally posted 2014-03-31 to WAI GL list from http://davidmacd.com/WCAG/wcag-html5-techniques-review.html

HTML 5 Techniques and WCAG

All techniques without notes can be used in HTML5, just add "HTML5" to the Applicability section. The only technique below that as of this writing to be assigned for update is H91 to Paul Working Group Techniques Development Assignments. H30 is waiting for someone to edit it.

WCAG HTML Technique David’s Notes Notes from the list
H2: Combining adjacent image and text links for the same resource    
H4: Creating a logical tab order through links, form controls, and objects    
H24: Providing text alternatives for the area elements of image maps    
H25: Providing a title using the title element    
H27: Providing text and non-text alternatives for object    
H28: Providing definitions for abbreviations by using the abbr and acronym elements Acronym deprecated in HTML5, leave ABBR as only example  
H30: Providing link text that describes the purpose of a link for anchor elements    
H32: Providing submit buttons  
H33: Supplementing link text with the title attribute This does not work because the title and the link text compete for the ACCNAME in the accessibility API. Screen readers can't get it. This has caused a lot of confusion over the years.

Response: This technique is called "supplementing link text with title..." the AAPI document says only provide the title element if there is no link text in the anchor. Its an either/or (not both/and) calculation. I agree that browsers should expose the title contents on keyboard focus, but browsers are actually calculating it properly with respect to the API. We can't "supplement" link text in the API with the title attribute, unless we lobby browsers and AT to violate the API mapping document and expose BOTH the anchor text AND the title attribute in the ACCNAME at the same time. This would be fundamental change to WAI ARIA. We could however rename the technique to "using the title attribute if the anchor text is empty", but we would have to provide a way for the title attribute to be exposed on keyboard focus. At least until browsers do that which is unlikely.

Jonathan Avila comments on list: The AAPI mapping document states to use title as the accessible description if it was not used in the accessible name calculation. This seems a very reasonable approach which is supported by at least some browser/AT combinations today so I don't think we should drop this. We should encourage more browsers to support it.;
H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline  
H35: Providing text alternatives on applet elements Applet deprecated in HTML 5  
H36: Using alt attributes on images used as submit buttons    
H37: Using alt attributes on img elements    
H39: Using caption elements to associate data table captions with data tables    
H40: Using definition lists    
H42: Using h1-h6 to identify headings    
H43: Using id and headers attributes to associate data cells with header cells in data tables We should revisit our requirements for this. Screen readers such as NVDA and JAWS now read correctly several layers of merged cell <th> tags  
H44: Using label elements to associate text labels with form controls    
H45: Using longdesc    
H46: Using noembed with embed Embed was not part of html 4 but is part of html5  
H48: Using ol, ul and dl for lists or groups of links    
H49: Using semantic markup to mark emphasized or special text Screen readers make no distinction between <b> and <strong> or <i> and <em>. <b> and <i> are back in HTML5. It was a theoretical concept that never helped in AT. Maybe it will in the future but I doubt it. Perhaps drop it...

Response: Partially agree that CSS sniffing would be difficult... was thinking more about the <b> vs. <strong> and <i> vs. <em> discussion... I think after 10 years of no tool making a distinction for PWD and no evidence of users styling em differently, that we could retire the technique if all agreed ... perhaps some tool will show up some day that will actually present <strong> in a different way than <b>... I opened the conversation up because HTML5 has resurrected <b> and <i> I have no <strong> feeling about the outcome, so will withdraw the comment.

Jonathan Avila comments on list: I think we should still recommend semantic markup for emphasis, etc. This item relates to Failure F2. Browsers for example italicize the em element. Some users with low vision have difficulty reading italic text and may desired to have style sheets that change how the em element is displayed. User shouldn’t be forced to guess at semantic meaning by looking at CSS rules when there is a semantic element available that should be used. Since this isn’t a failure I think we should keep the H49.
H51: Using table markup to present tabular information    
H53: Using the body of the object element    
H54: Using the dfn element to identify the defining instance of a word    
H56: Using the dir attribute on an inline element to resolve problems with nested directional runs    
H57: Using language attributes on the html element    
H58: Using language attributes to identify changes in the human language    
H59: Using the link element and navigation tools    
H60: Using the link element to link to a glossary    
H62: Using the ruby element    
H63: Using the scope attribute to associate header cells and data cells in data tables The scope attribute is more important than many previously estimated...Without it Screen readers get mixed up in the the top row of a simple table that has column headers. They read all the <th> elements to the left of a <th> as headers for the cell that has focus  
H64: Using the title attribute of the frame and iframe elements    
H65: Using the title attribute to identify form controls when the label element cannot be used    
H67: Using null alt text and no title attribute on img elements for images that AT should ignore Add that there should also be no wai aria attributes (aria-label, labelledby, describedby)  
H69: Providing heading elements at the beginning of each section of content    
H70: Using frame elements to group blocks of repeated material No indication anyone ever did this. It is an artifact from WCAG 1, frames are dropped from HTML5, and no indication it is actually useful. I think we should drop this.  
H71: Providing a description for groups of form controls using fieldset and legend elements    
H73: Using the summary attribute of the table element to give an overview of data tables Summary dropped from HTML5, not coming back. aria describedby on the table element is taking over. Works in NVDA, but not in JAWs yet. describedby can also refer to a paragraph in the details element so hide describtion visually, but discoverable on expand.  
H74: Ensuring that opening and closing tags are used according to specification    
H75: Ensuring that Web pages are well-formed    
H76: Using meta refresh to create an instant client-side redirect    
H77: Identifying the purpose of a link using link text combined with its enclosing list item    
H78: Identifying the purpose of a link using link text combined with its enclosing paragraph I think we should drop this in favour of giving context in aria-label ARIA8. In 8 years have never seen it screen reader user get link context this way. We should also write an aria-describedby solution referring to the suplementary text.

Response: yes, we have a labelledby technique which is sufficient and an aria-label technique, we have no describedby example yet. Describedby addresses the issue that an AT could potentially be developed to outline the associated text. Labelledby on links requires a reference to both the supplementary text and the current element so that the ACCNAME in the API will provide both. The advantage of describedby is that it maps to ACCDESCRIPTION while the anchor text maps to ACCNAME so there is no need for self reference. The advantage of aria-label is that it shows up in the JAWS link list. I suggest we explain strengths and weaknesses of each. The main point is that I think we should retire H78, H80, and H81 given the wealth of new ways to explicitly provide context. These were compromise techniques for "click here" developed before WAI ARIA solved the problem.

Jonathan Avila comments on list: I prefer a technique that uses aria-labelled by rather than aria-label. This will help users with low vision and cognitive impairments as reading tools could highlight the link as well as any corresponding on-screen text indicated by aria-labelledby.
H79: Identifying the purpose of a link using link text combined with its enclosing table cell and associated table headings    
H80: Identifying the purpose of a link using link text combined with the preceding heading element See comments on H78 above. See Jonathan Avila comments on H78 above.
H81: Identifying the purpose of a link in a nested list using link text combined with the parent list item under which the list is nested See comments on H78 above. See Jonathan Avila commments in H78 above.
H83: Using the target attribute to open a new window on user request and indicating this in link text    
H84: Using a button with a select element to perform an action    
H85: Using OPTGROUP to group OPTION elements inside a SELECT    
H86: Providing text alternatives for ASCII art, emoticons, and leetspeak    
H87: Not interfering with the user agent's reflow of text as the viewing window is narrowed    
H88: Using HTML according to spec    
H89: Using the title attribute to provide context-sensitive help    
H90: Indicating required form controls using label or legend    
H91: Using HTML form controls and links    
H92: Including a text cue for colored form control labels    
H93: Ensuring that id attributes are unique on a Web page    
H94: Ensuring that elements do not contain duplicate attributes