Re: 1.3.1 question

I would like to introduce a new failure based on this discussion.

"Failure of 1.3.1 due to visually distinct headers, footers, navigation
bars, main content, or asides providing no ACCESSIBLE NAME (or ACCESSIBLE
DESCRIPTION)"

WCAG does not require any specific technique to do this (landmarks, html 5
<nav> etc, and headings could all work), however, in the API the ACCNAME,
or ACCDESCRIPTION need to be populated with meaningful Label (Name).



On Mon, Apr 4, 2016 at 3:35 PM, Gregg Vanderheiden <
gregg@raisingthefloor.org> wrote:

> Hmmm
>
> actually, you can document a failure if there is a fail — at any point in
> time.   A fail is like a technique.
>
> Failures  (full name is    common failure  )  is
>
>    - something that ALWAYS fails the SC as written
>    - is common - and therefore worth documenting.
>
>
> failures never modify WCAG - they just document what is a failure  (ALWAYS
> a failure on all content)
> We can add failures at any time we see one
> we have to remove failures if things change and they are no longer ALWAYS
> a failure (or because we find times when they would not be a fail)
>
>
>
> *gregg*
>
> On Apr 4, 2016, at 4:10 AM, Alastair Campbell <acampbell@nomensa.com>
> wrote:
>
> I’ll just +1 John & Gregg’s responses, we can’t make a fail of something
> that didn’t exist when WCAG 2.0 came out, although it might be the best
> practice in many cases.
>
> I think it’s also a useful example when considering how WCAG.next might
> work, as it is something that could be strengthened in the guidelines in
> response to updated technology.
>
> -Alastair
>
>
>