- From: Claudio Luis Vera <claudio@simple-theory.com>
- Date: Fri, 2 Mar 2018 09:55:03 -0500
- To: Glenda Sims <glenda.sims@deque.com>
- Cc: WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <CADR+Rv-P4G8V6-PC4E9y9+PmoEWorp0OpOwqeW9S46-owRf6_Q@mail.gmail.com>
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
Received on Friday, 2 March 2018 14:55:34 UTC