- From: ALAN SMITH <alands289@gmail.com>
- Date: Mon, 4 Apr 2016 15:51:03 -0400
- To: "Patrick H. Lauke" <redux@splintered.co.uk>, "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
- Message-ID: <5702c5a8.d519810a.88c6f.54ec@mx.google.com>
My bad, 1.3.3 as it deals with shapes. Sent from Mail for Windows 10 From: Patrick H. Lauke Sent: Monday, April 4, 2016 3:46 PM To: w3c-wai-gl@w3.org Subject: Re: 1.3.2 question for shapes/icons alone that are used everywhere now but were not back in 2008 Failing to see the relation to 1.3.2. Did you mean 3.3.2? (In which case I'd say yes, having a pure icon with no appropriate alternative text would fail 3.3.2 and 4.1.2, as well as 1.1.1) On 04/04/2016 20:34, ALAN SMITH wrote: > All, > > Are icons/shapes with no labels or descriptions a violation of 1.3.2 TODAY? > > They were not as prevalent back in 2008 as they are now with today’s > graphics usage. > > Shape/icons like: > > Stars for favorites > > Hearts for favorites > > Gears for Settings > > Shopping carts for, well, shopping carts > > X for Close > > X within a circle for Close > > + for expand or more > > -For collapse or less > > Social media icons for Facebook, Linkedin, Instagram Twitter and the lot > of them > > Arrows pointing down for more sub-menus or expand > > Arrows pointing up for collapse back up > > Arrows pointing to the right for advance right for carousels or > selectable for link list items > > Arrows pointing to the left for move to the left in carousels > > Colored flags for national language or monetary support for shopping sites > > Needing alt text may be 1.1.1 but since they are shapes that would not > have instructions they may be teachable items for 1.3.2 for developers. > > I don’t see any of the automated testing tools having these in their > testing. > > Since we do have in F26: “Failure of Success Criterion 1.3.3 due to > using a graphical symbol alone to convey information” I think we have a > precedent. > > Regards, > > Alan > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > *From: *Wayne Dick <mailto:wayneedick@gmail.com> > *Sent: *Monday, April 4, 2016 2:44 PM > *To: *Katie Haritos-Shea GMAIL <mailto:ryladog@gmail.com> > *Cc: *David MacDonald <mailto:david100@sympatico.ca>; WCAG > <mailto:w3c-wai-gl@w3.org>; Mike Elledge <mailto:melledge@yahoo.com>; > Andrew Kirkpatrick <mailto:akirkpat@adobe.com>; Patrick H. Lauke > <mailto:redux@splintered.co.uk>; ALAN SMITH > <mailto:alands289@gmail.com>; Paul Adam <mailto:paul.adam@deque.com> > *Subject: *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 > <mailto: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 <mailto: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 <tel:703-371-5545> **|****ryladog@gmail.com* > <mailto:ryladog@gmail.com>***|****Oakton, VA **|****LinkedIn > Profile* > <http://www.linkedin.com/in/katieharitosshea/>***|****Office: > 703-371-5545 <tel:703-371-5545>* > > *From:* Wayne Dick [mailto:wayneedick@gmail.com > <mailto:wayneedick@gmail.com>] > *Sent:* Monday, April 4, 2016 1:47 PM > *To:* Katie Haritos-Shea GMAIL <ryladog@gmail.com > <mailto:ryladog@gmail.com>> > *Cc:* David MacDonald <david100@sympatico.ca > <mailto:david100@sympatico.ca>>; WCAG <w3c-wai-gl@w3.org > <mailto:w3c-wai-gl@w3.org>>; Mike Elledge <melledge@yahoo.com > <mailto:melledge@yahoo.com>>; Andrew Kirkpatrick > <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>; Patrick H. > Lauke <redux@splintered.co.uk <mailto:redux@splintered.co.uk>>; > ALAN SMITH <alands289@gmail.com <mailto:alands289@gmail.com>>; > Paul Adam <paul.adam@deque.com <mailto: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 <mailto: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 <tel:703-371-5545> > **|****ryladog@gmail.com* > <mailto:ryladog@gmail.com>***|****Oakton, VA **|****LinkedIn > Profile* > <http://www.linkedin.com/in/katieharitosshea/>***|****Office: 703-371-5545 > <tel:703-371-5545>* > > *From:* David MacDonald [mailto:david100@sympatico.ca > <mailto:david100@sympatico.ca>] > *Sent:* Monday, April 4, 2016 12:38 PM > *To:* Katie Haritos-Shea GMAIL <ryladog@gmail.com > <mailto:ryladog@gmail.com>> > *Cc:* WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>; > Mike Elledge <melledge@yahoo.com > <mailto:melledge@yahoo.com>>; Andrew Kirkpatrick > <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>; Patrick H. > Lauke <redux@splintered.co.uk > <mailto:redux@splintered.co.uk>>; ALAN SMITH > <alands289@gmail.com <mailto:alands289@gmail.com>>; Paul > Adam <paul.adam@deque.com <mailto: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 <mailto: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 <tel:703-371-5545> > **|****ryladog@gmail.com* > <mailto:ryladog@gmail.com>***|****Oakton, VA > **|****LinkedIn Profile* > <http://www.linkedin.com/in/katieharitosshea/>***|****Office: > 703-371-5545 <tel:703-371-5545>* > > *From:* David MacDonald [mailto:david100@sympatico.ca > <mailto:david100@sympatico.ca>] > *Sent:* Monday, April 4, 2016 11:28 AM > *To:* w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> > *Cc:* Mike Elledge <melledge@yahoo.com > <mailto:melledge@yahoo.com>>; Andrew Kirkpatrick > <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>; > Patrick H. Lauke <redux@splintered.co.uk > <mailto:redux@splintered.co.uk>>; ALAN SMITH > <alands289@gmail.com <mailto:alands289@gmail.com>>; Paul > Adam <paul.adam@deque.com <mailto: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 <mailto: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 <mailto:melledge@yahoo.com> > *Sent: *Monday, April 4, 2016 9:37 AM > *To: *Andrew Kirkpatrick > <mailto:akirkpat@adobe.com>; Patrick H. Lauke > <mailto:redux@splintered.co.uk>; w3c-wai-gl@w3.org > <mailto: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 <mailto: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 <mailto: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 > <mailto: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 surveyhttps://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 <http://www.splintered.co.uk> | > https://github.com/patrickhlauke > >http://flickr.com/photos/redux/ > <http://flickr.com/photos/redux/>| > http://redux.deviantart.com > <http://redux.deviantart.com/> > >twitter: @patrick_h_lauke | skype: patrick_h_lauke > > > -- 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
Received on Monday, 4 April 2016 19:51:34 UTC