Re: 1.3.1 question

What additional benefit would adding an accessible name to a page header or footer have?  That would just add extra verbosity e.g. Header header when announced by a screen reader.

Jon

Sent from my iPhone

On Apr 4, 2016, at 5:49 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:

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<mailto: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<mailto: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