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