W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2018

Re: Having h5 after h2 is a violation as per 1.3.1 info & relationships. - was: WCAG violations or accessibility enhancements

From: Denis Boudreau <dboudreau01@gmail.com>
Date: Fri, 2 Mar 2018 10:12:41 -0500
Message-ID: <CABvOyGB46No6fzxpcNfAun2PPR3WvjXt2s-iAYmfU3Jt-7RKXA@mail.gmail.com>
To: Claudio Luis Vera <claudio@simple-theory.com>
Cc: Glenda Sims <glenda.sims@deque.com>, WAI Interest Group <w3c-wai-ig@w3.org>
Oh there. Oh well. Patrick beat me to it. ;p


/Denis


--
Denis Boudreau
» dboudreau01@gmail.com
» 514-730-9168

On Fri, Mar 2, 2018 at 10:11 AM, Denis Boudreau <dboudreau01@gmail.com>
wrote:

> Interesting, but it painfully reminds me of the whole document outline
> algorithm that floated around for about 6 or 7 years with HTML5, until it
> was dropped 2-3 years ago due to blatant lack of user agent support.:
> http://html5doctor.com/computer-says-no-to-html5-document-outline/.
>
>
> /Denis
>
>
> --
> Denis Boudreau
> » dboudreau01@gmail.com
> » 514-730-9168 <(514)%20730-9168>
>
> On Fri, Mar 2, 2018 at 9:55 AM, Claudio Luis Vera <
> claudio@simple-theory.com> wrote:
>
>> Right on, Glenda! That would be one way to have the header level set
>> itself automatically, separate from typography.
>>
>> On Fri, Mar 2, 2018 at 9:51 AM, Glenda Sims <glenda.sims@deque.com>
>> wrote:
>>
>>> Crazy idea o' the week.  This problem of heading structure never happens
>>> to us in ordered lists..because we let the browsers render the list
>>> numbers.  Wouldn't it be super cool if we could have a similar construct in
>>> html for headings.
>>>
>>> I've only had one cup o' coffee....so this may not be the best idea I
>>> ever had...
>>>
>>> Example of dynamic heading structure
>>> <oh>  Glenda's make believe ordered headings
>>>    <hi>  Glenda's make believe heading item </hi>
>>>    <oh>
>>>         <hi> Another make believe heading item </hi>
>>> <!--#include file="includewithheading.html" -->
>>>         <hi>The last heading in this example</hi>
>>> <!-- end of include -->
>>>     </oh>
>>> </oh>
>>>
>>> And this would render as if I had coded it the "old fashioned way":
>>>
>>> <h1>Glenda's make believe heading item</h1>
>>> <h2>Another make believe heading item<h2>
>>> <h2>The last heading in this example</h2>
>>>
>>> Going to get a second cup o' coffee now...
>>> Goodwitch
>>>
>>> glenda sims  |   team a11y lead   |    deque.com    |    512.963.3773
>>> <(512)%20963-3773>
>>> *web for everyone. web on everything.* -  w3 goals
>>>
>>> [image: IAAP International Association of Accessibility Professionals:
>>> Certified Professional in Accessibility Core Competencies (CPACC)]
>>> <http://www.accessibilityassociation.org/certification>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 2, 2018 at 8:22 AM, Claudio Luis Vera <
>>> claudio@simple-theory.com> wrote:
>>>
>>>> There's a core UX problem with all document software that's leading to
>>>> this header issue. When authors create content in a program like Word,
>>>> they're largely selecting headers to set up typographical fenceposts in
>>>> their documents. For someone who has no knowledge of accessibility, a
>>>> choice of header has everything to do with font size, color, boldness, and
>>>> paragraph spacing. They're also making these choices based on what they
>>>> feel is the appropriate contrast and emphasis with the underlying text --
>>>> much as a person speaking would modulate the volume of their voice. As a
>>>> visual designer, I myself have skipped header levels for years before
>>>> becoming aware of their importance to users of screen readers.
>>>>
>>>> The problem lies in that authoring tools by default have a 1:1 match
>>>> between the typographic style and a single header level. To make an
>>>> oversize h3 look like an h5, well, you have to use an h5 and skip
>>>> header levels.
>>>> A more conscious or experienced user might create a template with
>>>> additional h3 styles that look like an h4 or h5, and give them names like
>>>> Header 3 Large, Header 3 Medium, and Header 3 Small.
>>>>
>>>> A better approach may be to separate the semantics of the header
>>>> structure from type choices by having the user flag something as a header,
>>>> then decide where it is to be nested in an outline panel -- and then choose
>>>> font sizes separately. This would prevent the authors from having headers
>>>> that are orphaned from their parents.
>>>>
>>>>
>>>>
>>>> On Thu, Mar 1, 2018 at 2:23 PM, David Best <davebest@cogeco.ca> wrote:
>>>>
>>>>> This, I believe, illustrates the fine line between WCAG criteria and
>>>>> usability preferences. Technically, I do not think it is a 1.3.1 violation,
>>>>> but it may create user confusion, as the screen reader question would be
>>>>> "what am I missing?". This may occur on dynamic pages, and may not
>>>>> necessarily be under the control of the web page if third party widgets are
>>>>> used. So, it is really a question of good design and branding.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> *From:* Phill Jenkins [mailto:pjenkins@us.ibm.com]
>>>>> *Sent:* March 1, 2018 01:30 PM
>>>>> *To:* Rakesh Paladugula
>>>>> *Cc:* Ramakrishnan Subramanian; w3c-wai-ig@w3.org
>>>>> *Subject:* Re: Having h5 after h2 is a violation as per 1.3.1 info &
>>>>> relationships. - was: WCAG violations or accessibility enhancements
>>>>>
>>>>>
>>>>>
>>>>> Why is
>>>>>         Having h5 after h2
>>>>> a violation of 1.3.1?
>>>>>         *1.3.1*
>>>>> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic>* Info
>>>>> and Relationships:* Information, structure
>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#structuredef>,
>>>>> and relationships
>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#relationshipsdef> conveyed
>>>>> through presentation
>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#presentationdef>can
>>>>> be programmatically determined
>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#programmaticallydetermineddef> or
>>>>> are available in text. (Level A)
>>>>>
>>>>> 1.3.1 doesn't require perfect nesting order - just that it can be
>>>>> programmatically determined.
>>>>>
>>>>> There are plently of examples of news type pages that may have a bold
>>>>> looking headline heading tagged as an <h2> followed in the reading order by
>>>>> a very small heading, such as  "Other Author Articles" tagged as an H5.
>>>>> What would be wrong with that per the Success Criteria?
>>>>>
>>>>> The Understanding 1.3.3
>>>>> <https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html>
>>>>> says: "The intent of this Success Criterion is to ensure that
>>>>> information and relationships that are implied by visual or auditory
>>>>> formatting are preserved when the presentation format changes. For example,
>>>>> the presentation format changes when the content is read by a screen reader
>>>>> . . . Sighted users perceive structure and relationships through various
>>>>> visual cues — headings are often in a larger, bold font separated from
>>>>> paragraphs by blank lines; . .
>>>>> under *Additional Techniques (Advisory) for 1.3.1*
>>>>> G141: Organizing a page using headings
>>>>> <http://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G141>
>>>>> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G141which says:
>>>>> "To facilitate navigation and understanding of overall document structure,
>>>>> authors should use headings that are properly nested (e.g., h1 followed by
>>>>> h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).
>>>>> Tests
>>>>> *Procedure*
>>>>>
>>>>> 2.        Check that a heading for each section exists.
>>>>>
>>>>>
>>>>> *Expected Results*
>>>>>
>>>>>    - Check #2 is true.
>>>>>
>>>>> Note that
>>>>> a.) G141 is an advisory techniue,
>>>>> b.) G141 does not say "shall" or "must",
>>>>> c.) G141 does not fail if the heading are not nested,
>>>>> d.) G141 passes if each section has a heading,
>>>>> e.) advisory techniques are best practices, not examples of failures
>>>>> to meet a Success Criteria,
>>>>> f.) Common Failures for SC 1.3.1 does not list an example with
>>>>> incorrectly nested headings .
>>>>>
>>>>>
>>>>> On 14-Feb-2018, at 11:41 AM, Ramakrishnan Subramanian <
>>>>> ram.eict2013@gmail.com> wrote:
>>>>>
>>>>> Heading order:
>>>>> Whether the following heading level is considered an accessibility
>>>>> violation? if yes, which criteria does this violate?
>>>>> The first heading level in the page is <h2> sample text </h2>
>>>>> The next heading level is <h5> sample text </h5>
>>>>> ___________
>>>>> Regards,
>>>>> Phill Jenkins
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 14-Feb-2018, at 11:41 AM, Ramakrishnan Subramanian <
>>>>> ram.eict2013@gmail.com> wrote:
>>>>>
>>>>> Dear Members,
>>>>> I hope it is appropriate to post this query here.
>>>>> I kindly request you to help me understand few of the accessibility
>>>>> related issues mentioned below.
>>>>> Whether these are treated as accessibility enhancement which would be
>>>>> helpful for the end user. Or accessibility violation.
>>>>> Heading order:
>>>>> Whether the following heading level is considered an accessibility
>>>>> violation? if yes, which criteria does this violate?
>>>>> The first heading level in the page is <h2> sample text </h2>
>>>>> The next heading level is <h5> sample text </h5>
>>>>>
>>>>> Landmark regions:
>>>>> When there are different content given inside two different aria
>>>>> region, with same aria label. Under which criteria this fails?
>>>>> <div role=”region” aria-label=”apple”>
>>>>> Apple related content goes here
>>>>> </div>
>>>>> <div role=”region” aria-label=”apple”>
>>>>> Bannana related content goes here
>>>>> </div>
>>>>> 3. Links which open in a new window:
>>>>> When there is no indication for the screen reader users for the link
>>>>> which opens in a new window, is that considered an accessibility
>>>>> violation? If yes, which criteria does this issue violate?
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Thanks and Regards
>>>>> Ramakrishnan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> User Experience | Information Architecture | Accessibility
>>>> simple-theory.com
>>>> +1 954-417-4188 <(954)%20417-4188>
>>>>
>>>>
>>>
>>
>>
>> --
>> User Experience | Information Architecture | Accessibility
>> simple-theory.com
>> +1 954-417-4188 <(954)%20417-4188>
>>
>>
>
Received on Friday, 2 March 2018 15:13:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 March 2018 15:13:46 UTC