Re: 1.3.1 question

Hi again,
I forgot to say that I use screen readers every day to read and navigate.
Sometimes I just use the screen reader to navigate. When I only have 25
words on the page it is important.

Wayne

On Mon, Apr 4, 2016 at 11:38 AM, Wayne Dick <wayneedick@gmail.com> wrote:

> Dear Katie et. al.
>
> The problem may be as simple as refurbishment.
> Question: Does a site that fails to identify semantically significant
> regions meet 1.3.1 today? When the site was launched it did, but today does
> it? I say yes, until the page undergoes a major change.
>
> At that point it is new code and needs to be audited for conformance. What
> passed before no longer passes since there are now techniques to remedy the
> old accessibility deficit.
>
> The point is this. Is 1.3.1 violated by lack of deterministic identifiers?
> Regarding headers and footers that are semantically void, the answer is
> yes. That is binding, how it is analyzed in light of new technology must
> change for WCAG to be a living document.
>
> Here is the failure.
> A site the uses new technologies to improve its general functionality,
> user interface or appearance and fails to correct old deficits that can
> fixed with current technology does not conform to WCAG after the general
> changes have been made. This applies to any success criterion that could
> not be addressed when the site met conformance originally.
>
> This does not rest on techniques, it is simply a matter of a new site
> (with an established URL) that no longer meets a normative success criteria.
>
> I think that does it.
>
> Wayne
>
>
>
> On Mon, Apr 4, 2016 at 10:57 AM, Katie Haritos-Shea GMAIL <
> ryladog@gmail.com> wrote:
>
>> Wayne,
>>
>>
>>
>> While this makes perfect sense, and in some governments and elsewhere
>> this model is used…WCAG itself cannot require this. Techniques are
>> INFORMATIVE and are not required – nor should they be. They present options
>> for how to meet the requirements of the SC.
>>
>>
>>
>> ​​​​​
>>
>>
>>
>>
>>
>>
>>
>> ** 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:* Wayne Dick [mailto:wayneedick@gmail.com]
>> *Sent:* Monday, April 4, 2016 1:47 PM
>> *To:* Katie Haritos-Shea GMAIL <ryladog@gmail.com>
>> *Cc:* David MacDonald <david100@sympatico.ca>; WCAG <w3c-wai-gl@w3.org>;
>> 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
>>
>>
>>
>> Use the Refurbishment Model.
>>
>> For years buildings have been exempt form architectural barrier upgrades
>> if they met requirements at some point. The next time the building is
>> refurbished it is brought up to code. This is to protect institutions that
>> adopt building codes early from endless change.
>>
>> Google and sites like it should follow this model. Next time they change
>> anything on their site, they come up to conformance. The techniques were
>> not available in 2008 to meet 1.3.1 for headers and footers.  They are now.
>>
>> Next time a page is upgraded, fix it.
>>
>> Wayne
>>
>>
>>
>>
>>
>> On Mon, Apr 4, 2016 at 9:50 AM, Katie Haritos-Shea GMAIL <
>> ryladog@gmail.com> wrote:
>>
>> David,
>>
>>
>>
>> That is a good idea, but, I am thinking of the conformance issue overall
>> – in that case, even though Techniques aren’t relative to conformance – I
>> would like to see the Update Model be consistent, across what we do….
>>
>>
>>
>> So in that vein, I would like to say that Techniques might best be mapped
>> to WCAG or WCAG/UAAG/ATAG specific versions, and then attach what we call
>> additional  **Best Practices** to the Requirements (Success Criteria)
>> and supporting materials to the NEXT version of the standard – as we see
>> them become relevant while folks are still conforming to an older version.
>> Then as folks begin to conform to the new version, they will or may have
>> already implemented those Best Practices, and will more rapidly be able to
>> conform to the new version of WCAG or WCAG/UAAG/ATAG.
>>
>>
>>
>> ​​​​​Does that make sense?
>>
>>
>>
>>
>>
>>
>>
>> ** 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:* David MacDonald [mailto:david100@sympatico.ca]
>> *Sent:* Monday, April 4, 2016 12:38 PM
>> *To:* Katie Haritos-Shea GMAIL <ryladog@gmail.com>
>> *Cc:* WCAG <w3c-wai-gl@w3.org>; 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
>>
>>
>>
>> Hi Katie
>>
>>
>>
>> Do you think creating a date field for failure techniques could work?
>> This might allow us to post failures as solutions become available.
>> Companies that have sites before the date don't need to worry about these
>> failures, whereas new sites would be expected to pay attention to them. Of
>> course WCAG WG would have nothing to do with enforcement... but it would
>> give us a way to write failures without disadvantaging old sites.
>>
>>
>>
>> We could do this in the "Applicability" section. "This failure applies to
>> content created after MM/DD/YYYY."
>>
>>
>>
>>  We will run into this situation in the next standard where techniques
>> are up to date but there missing failures as things on the web change. I
>> think this might address our original intent in WCAG 2 of having an ever
>> green standard.
>>
>>
>>
>> On Mon, Apr 4, 2016 at 11:51 AM, Katie Haritos-Shea GMAIL <
>> ryladog@gmail.com> wrote:
>>
>> 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 <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:* 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> *From: *Mike Elledge <melledge@yahoo.com>
>> *Sent: *Monday, April 4, 2016 9:37 AM
>> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>; Patrick H. Lauke
>> <redux@splintered.co.uk>; 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
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>