- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Mon, 4 Apr 2016 20:44:20 +0100
- To: w3c-wai-gl@w3.org
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:44:48 UTC