Re: 1.3.1 question

Hi All,

I just want to point out one import part of that Success Criteria, and that
is the final 5 words of that SC: "...or are available in text."

While I completely understand that the desire to ensure that "the web is as
accessible as it can be" is a strong motivator, we must also be careful to
not try and read more into what the current success criteria says, or
insist on content authors using technologies that weren't even available
when WCAG 2.0 was released. That is revisionist history, and it can cause
serious legal concerns for large companies and corporations that are
managing 100's of thousands of web documents. A web page that was
conformant to WCAG 2.0 in 2009 *MUST *also be conformant today: that is
simply how technical standards work. That's today's Modern Web as well.

While I would agree that using ARIA or HTML5 landmarks is certainly a Best
Practice, and I would take every opportunity to encourage a developer to
use those techniques, WCAG 2.0 cannot become some form of bully stick to
force developers into retroactively changing legacy content that would be
"non-conformant" today simply because a SME wants to enforce a Best
Practice that wasn't even available when WCAG 2.0 was finalized. That is
both dishonest and problematic.

For Example, WCAG 2.0 SC 1.3.1 also lists as a possible Technique for
Success Technique #G117 (https://www.w3.org/TR/WCAG20-TECHS/G117.html)
which does not take advantage of either ARIA or HTML5 landmark roles.

Another way of meeting this Success Criteria (and one that was used quite
extensively when WCAG 2.0 was first released) was through the use of @title
and proper heading structure:

<div title="Site Menu">
  <h2>Elsewhere On This Site</h2>
   <ul>
     <li>Here</li>
     <li>There</li>
     <li>Somewhere Else</li>
  </ul>
</div>

I don't think anyone can mount a credible argument that suggests that the
above code sample DOES NOT meet the intent of SC 1.3.1, a point that
Technique #G115 makes quite clear:
https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/G115

Finally, the Success Criteria itself explicitly states the following: "...when
technologies support programmatic relationships, it is *strongly encouraged*
that information and relationships be programmatically determined rather
than described in text." (
https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20160317/content-structure-separation-programmatic.html
)

Not *MUST*, but *Strongly Encouraged*. I think that it is important that we
not overstep the existing boundaries that WCAG has in place, simply in the
zeal of attempting to enforce what are clearly Best Practices, but NOT
mandated Requirements of WCAG 2.0, and any attendant laws
and legislation that uses WCAG 2.0 as its foundation.

JF

On Fri, Apr 1, 2016 at 7:12 PM, Katie Haritos-Shea GMAIL <ryladog@gmail.com>
wrote:

> I am not sure we should be REQUIRING ARIA, when this can be done with
> HTML5 semantic structure for navigation, sections, and headings. I would
> not agree to requiring ARIA over HTML.
>
>
>
> ​​​​​
>
>
>
>
>
>
>
> ** katie **
>
>
>
> *Katie Haritos-Shea*
> *Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)*
>
>
>
> *Cell: 703-371-5545 <703-371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <703-371-5545>*
>
>
>
> *From:* Mike Elledge [mailto:melledge@yahoo.com]
> *Sent:* Friday, April 1, 2016 7:57 PM
> *To:* Paul J. Adam <paul.adam@deque.com>
> *Cc:* David MacDonald <david100@sympatico.ca>; Andrew Kirkpatrick <
> akirkpat@adobe.com>; jon.avila@ssbbartgroup.com; ALAN SMITH <
> alands289@gmail.com>; WCAG <w3c-wai-gl@w3.org>
> *Subject:* Re: 1.3.1 question
>
>
>
> I agree that they should be required. I've always been in favor of them,
> and the argument that they are visually distinct is persuasive.
>
>
>
> Mike
>
>
> On Apr 1, 2016, at 7:42 PM, Paul J. Adam <paul.adam@deque.com> wrote:
>
> Not sure if everyone here is on the github where I sent some of my first
> few responses why they’re required. If you’ve already read it sorry! Pasted
> my arguments for why landmarks are required below:
>
> —————
>
> Both www.google.com and www.apple.com have a clearly designed header and
> footer areas that visually stand out as the header and footer sections. The
> navigation areas also stand out visually. Most all real-word websites have
> the same visually identifiable headers, footers, main content areas, and
> navigation areas.
>
>
>
> *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)
>
>
>
> So the page’s structure is conveyed through presentation clearly. This
> structure must also be programmatically determinable to AT.
>
>
>
> Landmarks and/or HTML5 semantic structural elements are the best way to
> meet that SC. There really is no other way to say that the large footer
> section on apple.com is the footer to a screen reader user other than
> using landmarks or <footer> tag. Otherwise they’d just have to guess the
> area of the page or you’d have to use visually hidden headings that say
> <h2>Footer Section:</h2>. No one uses a visually hidden heading method to
> make their page’s structure programmatically determinable.
>
>
>
> Apple’s footer area:
>
> <PastedGraphic-16.png>
>
>
>
> Apple wraps their footer area in a contentinfo landmark and wraps the
> footer navigation in a navigation landmark.
>
>
>
> <PastedGraphic-17.png>
>
> I have heard people argue that landmarks could not possibly be required by
> WCAG because they were not invented when WCAG was released. That’s a weak
> argument that would lead to exclusions for mobile native apps as those were
> not around either when WCAG came out.
>
>
>
> ——————
>
>
>
> I’m saying that you have to use either ARIA Landmarks, HTML5 Semantic
> Structural Tags, or both. One or both are required.
>
>
>
> ——————
>
>
>
> I’m talking about real world websites like apple.com, google.com,
> adobe.com, deque.com these all require landmarks. If it’s just a plain
> page with no header, footer, no navigation those landmarks would not be
> required. However, if a basic page has a clearly defined main content area
> styled to look that way visually then we’d have to make that
> programmatically determinable to AT.
>
>
>
> ——————
>
>
>
> Folks don’t use off screen text to convey their header, footer,
> navigation, or main content areas. Sure it’s possible to do that but I’ve
> never seen it done!
>
>
>
> It seems very obvious that most headers, footers, navigations all have a
> very distinct visual design, gray backgrounds, solid rectangle borders,
> something to really help them stand out visually to sighted users. Sighted
> users have the visual cues to quickly identify these page areas.
>
>
>
> It’s always been an issue that sighted folks get the visual design and
> screen reader users have not received that same presentation conveyed in a
> method they can understand via their AT.
>
>
>
> I’ll volunteer to write a failure technique.
>
>
>
> I’ve never written one before but here’s a first draft idea.
>
> ———————
>
> F131: Failure of Success Criterion 1.3.1 due to conveying structure and
> relationships through presentation that are not programmatically
> determinable.
>
>
>
> Tests
>
>
>
> Procedure
>
>
>
> 1. Check that the structure and relationships conveyed through
> presentation are also programmatically determinable.
>
>
>
> Expected Results
>
>
>
> 1. If check #1 is false then this failure condition applies.
>
> ———————
>
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>
>
> On Apr 1, 2016, at 6:18 PM, David MacDonald <david100@sympatico.ca> wrote:
>
>
>
> I want to say yes, it fails without landmarks that have an accessible
> name, but how could that be, we had no technique until 4 years after WCAG
> was published...
>
>
>
> I mark it as Best Practice on reports. I'd love for us to decide it's a
> failure...
>
>
>
> On Fri, Apr 1, 2016 at 6:23 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
> Focusing in on the specific question, do people agree or disagree that
> landmarks are required to meet 1.3.1?  Would google.com (or other sites
> with a footer area that is shown presentationally) fail 1.3.1 if they don’t
> provide landmarks?
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
> http://blogs.adobe.com/accessibility
>
>
>
> *From: *Jonathan Avila <jon.avila@ssbbartgroup.com>
> *Date: *Friday, April 1, 2016 at 16:59
> *To: *"alands289@gmail.com" <alands289@gmail.com>, Andrew Kirkpatrick <
> akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
> *Subject: *RE: 1.3.1 question
>
>
>
> Ø  With a page that has multiple “navigation regions” labeling is
> important.
>
>
>
> IMO, if a page has multiple landmarks such as multiple navigation regions
> at the same level then they would need an accessible name.  Providing an
> accessible name for the sole header at the top of the page and the sole
> footer at the bottom of the page seem too verbose in my opinion.  So if we
> choose to require accessible names for landmark we need to be very as to
> when they would be required so we have a testable way to make a
> determination.
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> jon.avila@ssbbartgroup.com
>
> 703.637.8957 (Office)
>
>
>
> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
> <https://twitter.com/SSBBARTGroup> | Facebook
> <https://www.facebook.com/ssbbartgroup> | Linkedin
> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog/>
>
> Check out our Digital Accessibility Webinars!
> <http://www.ssbbartgroup.com/webinars/>
>
>
>
> *From:* ALAN SMITH [mailto:alands289@gmail.com <alands289@gmail.com>]
> *Sent:* Friday, April 01, 2016 4:53 PM
> *To:* Andrew Kirkpatrick; WCAG
> *Subject:* RE: 1.3.1 question
>
>
>
> It is my understanding that they also need labeling beyond the announced
> “Contentinfo or footer landmark/region” or “Navigation landmark/region”.
> Window-Eyes grabs the adjacent text in the code and appends it to the label
> it displays in its Landmarks list. This is not always what the landmark
> really is and can be misleading.
>
>
>
> Since all the screen readers can jump to landmarks/regions it is a
> valuable item to have on the page.
>
> It provides an understanding of the structure and meaningful sequence
> which is 1.3.2.
>
>
>
> With a page that has multiple “navigation regions” labeling is important.
>
>
>
> Is it required? For 1.3.2 I think so.
>
> 1.3.2 is a very vague and often ambiguous guideline IMO.
>
>
>
> Regards,
>
>
>
> Alan
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Andrew Kirkpatrick <akirkpat@adobe.com>
> *Sent: *Friday, April 1, 2016 4:32 PM
> *To: *WCAG <w3c-wai-gl@w3.org>
> *Subject: *1.3.1 question
>
>
>
> Jon raised a question in response to a tweet from Paul Adam and we would
> like to get the group’s opinions.
>
>
>
> The issue is #171 (https://github.com/w3c/wcag/issues/171) and speaks to
> the need to follow techniques such as ARIA11 (
> https://www.w3.org/TR/WCAG20-TECHS/ARIA11.html) to mark regions of a page.
>
>
>
> The discussion so far is that authors might accomplish this with HTML5
> elements (e.g. Header, footer, etc) or using ARIA landmark roles  (e.g.
> Navigation, contentinfo, main).
>
>
>
> SC 1.3.1 reads:
>
> Info and Relationships: Information, structure, and relationships conveyed
> through presentation can be programmatically determined or are available in
> text.
>
>
>
> What do people think?  For a site like http://google.com – does this page
> fail 1.3.1 because it doesn’t mark the header and footer areas?
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
> http://blogs.adobe.com/accessibility
>
>
>
>
>
>
>
>


-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion