W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2016

Re: Current gaps in WCAG 2 as reported by Funka to the EU

From: Detlev Fischer <detlev.fischer@testkreis.de>
Date: Mon, 7 Nov 2016 21:41:11 +0100
Cc: WCAG <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
Message-Id: <BBED6C7F-E930-4880-83D4-B0BEE6F49FC0@testkreis.de>
To: David MacDonald <david100@sympatico.ca>
Just picking up Funka’s stated omission regarding search and playing around with a feasible coverage in a new SC, just to stoke up discussion:

2.X.X "Where a site-wide search function is offered, it is placed before the main content (???) and can be programmatically identified."
 
Technique: Placing and signposting the search function
A search function is placed before the content / main area, AND it can be identified programmatically, e.g. by
- a landmark role=search
- a heading (accessibly hidden or visible) labelling the search area
[The following options overlap with 2.4.6 Headings and Labels and 3.3.2 Labels or Instructions and may therefore better be dropped:]
- a fieldset with a legend identifying the search function
- a text input of type search with an accessible name identifying the field as search field

Would this ever be something that can be assessed and rated independent of other criteria like 2.4.6 or 3.3.2? Where would be draw the line? Would evaluators then in effect “punish” the same defect twice?

I am not entirely sure that the lack of a descriptive section for search would constitute an omission worth a “fail” of 1.3.1 or 2.4.1 IF the search field itself has a proper accessible name and is followed by a properly named button or input type submit. When placed before content is then likely to be discoverable quickly by SR users knowing how to jump to next text fields (but not everyone knows that).

An author right now using landmarks on just nav and main would now probably get a pass of 2.4.1 when the search field has an accessible name but the search section is not explicitly marked up via landmark or heading  - at least this is my guess.

Where I see an SC opportunity that may also cover Funka’s stated neglect of search is a more general stipulation to mark up  (via native elements or landmarks with label / labelled-by areas) all IMPORTANT sections on the page when present. Ideally thos would be an extenction of 2.4.1 in Silver but for now another SC? Is anyone working on such a thing? Still hard to define as a pass/fail technique…

Thoughts?

Detlev

- 

> On 7 Nov 2016, at 17:46, David MacDonald <david100@sympatico.ca> wrote:
> 
> 
> The following article identifies the following gaps​ proposed by Funka, an influential player in Europe, most of these criticisms are addressed in gap analysis by the Task Forces ​but may help us as we make decisions about priorities for 2.1:
> 
> - "What the WCAG doesn´t say is where this search function should be placed, how it should work or how the results should be presented. This is a general problem with the guidelines. They state that certain functions should exist, but say nothing about the quality of these functions."
> 
> -"the guidelines do not mention that interfaces should work with a mouse as well [as keyboard]. 
> 
> - "Neither do they bring up the touch screen as a possible input device."
> 
> - "WCAG does not reflect the fact that a PC is just one way of accessing the Web today."
> 
> -​ ​"The WCAG contains very few guidelines concerning design and cognition, and the few advices that are given in this area are found at level AAA. In other words, the EU’s proposed directive does not include luxuries such as:​ ​Being able to see where you are in the navigation structure.​, ​Finding comprehensible information in different formats, such as text, illustrations, photos, audio and video​, ​Getting relevant feedback, for example when you’re filling in a form.​"
> ​
> Full article here:
> http://www.funka.com/en/about-funka/ceos-corner/why-wcag-isnt-enough/ <http://www.funka.com/en/about-funka/ceos-corner/why-wcag-isnt-enough/>
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
>             Including those with disabilities
> 
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>

Received on Monday, 7 November 2016 20:41:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:07 UTC