View source for Review of html4 to html5

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 &quot;HTML5&quot; 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.
{| class="wikitable sortable"
  |-
    !data-sort-type="text" | WCAG HTML Technique || David’s Notes || Notes from the list
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H2.html H2:    Combining adjacent image and text links for the same resource] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H4.html H4:    Creating a logical tab order through links, form controls, and objects] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H24.html H24:    Providing text alternatives for the area elements of image maps] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H25.html H25:    Providing a title using the title element] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H27.html H27:    Providing text and non-text alternatives for object] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H28.html H28:    Providing definitions for abbreviations by using the abbr and acronym elements]|| <strong> Acronym</strong> deprecated in HTML5, leave ABBR as only example || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H30.html H30:    Providing link text that describes the purpose of a link for anchor elements]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H32.html H32:    Providing submit buttons] || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H33.html H33:    Supplementing link text with the title attribute] || This does not work because the <strong>title</strong> 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. 

<b>Response:</b> 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 [http://oaa-accessibility.org/example/40/ title attribute to be exposed on keyboard focus.] At least until browsers do that which is unlikely.

|| Jonathan Avila comments on list: The [http://www.w3.org/TR/html-aapi/#a-element 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.;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H34.html H34:    Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline]|| &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H35.html H35:    Providing text alternatives on applet elements]|| <strong>Applet</strong> deprecated in HTML 5 || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H36.html H36:    Using alt attributes on images used as submit buttons]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H37.html H37:    Using alt attributes on img elements]|| &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H39.html H39:    Using caption elements to associate data table captions with data tables]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H40.html H40:    Using definition lists]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H42.html H42:    Using h1-h6 to identify headings]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H43.html 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 &lt;th&gt; tags || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H44.html H44:    Using label elements to associate text labels with form controls]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H45.html H45:    Using longdesc]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H46.html H46:    Using noembed with embed] || Embed was not part of html 4 but is part of html5 || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H48.html H48:    Using ol, ul and dl for lists or groups of links] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H49.html H49:    Using semantic markup to mark emphasized or special text]||  Screen readers make no distinction between &lt;b&gt; and &lt;strong&gt; or &lt;i&gt; and &lt;em&gt;. &lt;b&gt; and &lt;i&gt; 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...

<b>Response:</b> Partially agree that CSS sniffing would be difficult... was thinking more about the &lt;b&gt; vs. &lt;strong&gt; and &lt;i&gt; vs. &lt;em&gt; 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 &lt;strong&gt; in a different way than &lt;b&gt;... I opened the conversation up because HTML5 has resurrected &lt;b&gt; and &lt;i&gt; I have no &lt;strong&gt; 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.  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H51.html H51:    Using table markup to present tabular information] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H53.html H53:    Using the body of the object element] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H54.html H54:    Using the dfn element to identify the defining instance of a word] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H56.html H56:    Using the dir attribute on an inline element to resolve problems with nested    directional runs]|| &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H57.html H57:    Using language attributes on the html element] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H58.html H58:    Using language attributes to identify changes in the human language] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H59.html H59:    Using the link element and navigation tools] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H60.html H60:    Using the link element to link to a glossary] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H62.html H62:    Using the ruby element] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H63.html 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 &lt;th&gt; elements to the left of a &lt;th&gt; as headers for the cell that has focus || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H64.html H64:    Using the title attribute of the frame and iframe elements] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H65.html H65:    Using the title attribute to identify form controls when the label element    cannot be used]|| &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H67.html 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) || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H69.html H69:    Providing heading elements at the beginning of each section of content] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H70.html 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. || &nbsp; 
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H71.html H71:    Providing a description for groups of form controls using fieldset and legend    elements]|| &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H73.html 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 <strong>expand</strong>. || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H74.html H74:    Ensuring that opening and closing tags are used according to specification] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H75.html H75:    Ensuring that Web pages are well-formed] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H76.html H76:    Using meta refresh to create an instant client-side redirect] || &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H77.html H77:    Identifying the purpose of a link using link text combined with its enclosing    list item]|| &nbsp; || &nbsp;
  
  |-
    ||[http://www.w3.org/TR/WCAG20-TECHS/H78.html 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 [http://www.w3.org/TR/WCAG20-TECHS/aria.html#ARIA8 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. 

<b>Response:</b>  yes, we have a [http://www.w3.org/TR/WCAG20-TECHS/aria.html#ARIA7 labelledby technique] which is sufficient and an [http://www.w3.org/TR/WCAG20-TECHS/aria.html#ARIA8 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.  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H79.html H79:    Identifying the purpose of a link using link text combined with its enclosing    table cell and associated table headings] || &nbsp;
   || &nbsp;
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H80.html 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. 
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H81.html 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. 
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H83.html H83:    Using the target attribute to open a new window on user request and    indicating this in link text] || &nbsp; || &nbsp;
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H84.html H84:    Using a button with a select element to perform an action] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H85.html H85:    Using OPTGROUP to group OPTION elements inside a SELECT] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H86.html H86:    Providing text alternatives for ASCII art, emoticons, and leetspeak] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H87.html H87:    Not interfering with the user agent's reflow of text as the viewing window is    narrowed] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H88.html H88:    Using HTML according to spec]|| &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H89.html H89:    Using the title attribute to provide context-sensitive help] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H90.html H90:    Indicating required form controls using label or legend] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H91.html H91:    Using HTML form controls and links] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H92.html H92:    Including a text cue for colored form control labels] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H93.html H93:    Ensuring that id attributes are unique on a Web page] || &nbsp; || &nbsp;
  
  |-
    || [http://www.w3.org/TR/WCAG20-TECHS/H94.html H94:    Ensuring that elements do not contain duplicate attributes] || &nbsp; || &nbsp;
  
|}