Re: 1.3.1 question

John, thank you for your comments. I agree with them, especially with the challenges and futility of retrofitting. As David mentioned, there is a natural evolution that enables the addition of new techniques (small "t") as website are updated or replaced. Katie is correct in pointing out that we need updated Techniques to provide guidance to the developers updating sites.
So maybe new requirements should remain best practices until WCAG next is introduced. But to David's point, how can we raise expectations so that those best practices are adopted as a matter of course, without turning them into requirements?
Mike
 

    On Monday, April 4, 2016 11:54 AM, Katie Haritos-Shea GMAIL <ryladog@gmail.com> wrote:
 

 #yiv9757300093 #yiv9757300093 -- _filtered #yiv9757300093 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv9757300093 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9757300093 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv9757300093 #yiv9757300093 p.yiv9757300093MsoNormal, #yiv9757300093 li.yiv9757300093MsoNormal, #yiv9757300093 div.yiv9757300093MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9757300093 a:link, #yiv9757300093 span.yiv9757300093MsoHyperlink {color:blue;text-decoration:underline;}#yiv9757300093 a:visited, #yiv9757300093 span.yiv9757300093MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv9757300093 span.yiv9757300093EmailStyle17 {color:#1F497D;}#yiv9757300093 .yiv9757300093MsoChpDefault {} _filtered #yiv9757300093 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv9757300093 div.yiv9757300093WordSection1 {}#yiv9757300093 David,  I agree that Techniques can and should be written to address these issues today, as they are *one possible way* to achieve the outcome the Success Criteria calls for.   But you are correct, we need to wait  before making any Failures until we have provide new Requirements, in an new standard version, that specifically states that they address these technologies. IMHO….  ​​​​​      * katie * Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA) Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545  From: David MacDonald [mailto:david100@sympatico.ca] 
Sent: Monday, April 4, 2016 11:28 AM
To: w3c-wai-gl@w3.org
Cc: Mike Elledge <melledge@yahoo.com>; Andrew Kirkpatrick <akirkpat@adobe.com>; Patrick H. Lauke <redux@splintered.co.uk>; ALAN SMITH <alands289@gmail.com>; Paul Adam <paul.adam@deque.com>
Subject: Re: 1.3.1 question  ​As per my first email in this thread, ​most of us agree that WCAG as currently written can't move the goal posts very easily as new great accessible technologies like ARIA are invented, for sites that previously met WCAG.   But I think Paul's fresh eyes do point out something I've thought about for a while as we do requirements gathering for WCAG NEXT. And perhaps even something we can do now...   WCAG 2 was designed to be every green. The success criteria were carefully written in order to ensure that as new technologies were invented, that they could be incorporated into WCAG. For the most part that has happened. We created Silverlight techniques, WAI ARIA techniques, and HTML5 techniques etc.  none of which were mature when WCAG2 was created.  However, our failure techniques have not kept pace with these new ways of doing things because we didn't want to create a situation where an old site that met WCAG no longer meets WCAG because a new failure was introduc  Naturally we want people to use the new technologies where there was no previous good solution. For instance, on new web sites- No page that has visually distinct headers, footers, Nav bars, main content, and asides should be without an ACCESSIBLE NAME  (and/or ACCESSIBLE DESCRIPTION) for those sections.- No link text should have an ambiguous ACCESSIBLE NAME  (or ACCESSIBLE DESCRIPTION), so the days of click here, read more, showing up in links lists should be a thing of the past.   HTML5 and WAI ARIA have solved these problems with new HTML elements, roles, aria-label, aria-labelledby etc...  So how can we ensure that new sites do take advantages of these new ways to solve old problems that previously were just hacked, or mostly not done at all?  I'd like to brainstorm a proposal. What if we create a date field on failure techniques? Agencies, legislature, and governments can use these date fields to determine if a certain failure is applicable based on when the content was created. The government of Ontario is a precident for this. They have a date on the AODA, because they understand that solvent companies create new web sites every few years. So they require the new sites meet WCAG. if we had date fields on our  new failures, then if the site was built after the failure was created it would fail SC 1.3.1 if there wansn't an ACCEISBLE NAME or DESCRIPTION on a section of  a page, or could fail that LEARN MORE link that didn't reference the description heading or provide an aria-label or title etc...  What do you think... could it work for WCAG NEXT, or even this version.?  On Mon, Apr 4, 2016 at 9:46 AM, ALAN SMITH <alands289@gmail.com> wrote:
Mike, I appreciate you sending this out. I had originally replied to the emails regarding 1.3.1 and landmarks about the use of landmarks/regions and their labeling  as a way to meet 1.3.2 (by these defining and providing a meaningful sequence to the page/information structure) as this was something I ran into and had be asked about.Since it is not listed in WCAG 2.0 1.3.2 and I agree that 1.3.2 can be subjective, I thought it warranted a question to the team. Best.  Alan Sent from Mail for Windows 10 From: Mike Elledge
Sent: Monday, April 4, 2016 9:37 AM
To: Andrew Kirkpatrick; Patrick H. Lauke; w3c-wai-gl@w3.org
Subject: Re: 1.3.1 question Hi All-- I'd like to understand better how persons who use screen readers feel about this issue. With WebAIM surveys indicating increased use of headings and regions I worry that we may be underestimating their benefit. I recognize that the application of 1.3.2 can be subjective, that flexibility in presenting data is important, and that bringing legacy applications into compliance can be time-consuming. Ultimately our objective has to be how to best serve the needs of users, however. Thoughts? Mike On Monday, April 4, 2016 8:21 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote: Patrick,
Thanks for chiming in, and welcome to the group!

Thanks of course to everyone who is contributing their opinions here, I’m just singling Patrick out as he just joined the WG two hours ago… :)

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility and Standards
Adobe 

akirkpat@adobe.com
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility





On 4/4/16, 06:54, "Patrick H. Lauke" <redux@splintered.co.uk> wrote:

>Apologies for jumping straight in here after only having been officially 
>nominated/joined...but as this whole discussion around 1.3.1 was the 
>trigger that made me officially join, here's what I've just sent as 
>comment to the survey https://www.w3.org/2002/09/wbs/35422/5April2016_misc/
>
>(with further apologies as this was probably already 
>touched-on/discussed here):
>
>Landmarks are not required. "Landmarks are *a* technique to provide 
>information/structure. They cannot be required (nor can any other 
>specific technique/implementation) as at the time WCAG 2.0 was 
>formalised they weren't even in existence/supported, to my knowledge. 
>Claiming they are would retrospectively fail sites that up until now 
>passed on this point.
>
>More generally, in my view there is no hard requirement to always having 
>to identify landmarks on every single page, in every single document. 
>Key here is "information important for comprehension will be perceivable 
>to all". Is every instance of a fairly clearly defined footer (perhaps 
>with a heading, a list of links to Ts&Cs, privacy policy, a copyright 
>notice) completely non-understandable to a user who cannot perceive its 
>styling? Will real users be confused by a lack of <footer> element or 
>relevant ARIA role? Further, is a role="region" (another sufficient 
>technique for 1.3.1) then NOT acceptable compared to role="contentinfo"?
>
>IF you determine that it is important to identify explicitly which part 
>of the page is the header, which is the footer, which is the main; IF 
>you don't deem it understandable enough for real users if these are 
>simply happening sequentially; IF you deem the structure of the overall 
>page so complex that a real user who can't visually perceive the page 
>structure would be confused/unable to understand it otherwise; THEN 
>something needs to be in place that further clarifies this structure. 
>you can choose aria landmarks, or aria regions, or headings, or some 
>other implementation that may not have even been dreamed up/documented 
>in the non-normative techniques document. the HOW is not important. what 
>matters is the end result: will a real user be less confused / 
>understand the overall structure of the page better than before. jumping 
>from this to "WCAG requires aria landmarks" is reaching.
>
>P
>-- 
>Patrick H. Lauke
>
>www.splintered.co.uk | https://github.com/patrickhlauke
>http://flickr.com/photos/redux/ | http://redux.deviantart.com
>twitter: @patrick_h_lauke | skype: patrick_h_lauke
>