Re: new coga SC #31 ready to be submitted

Hi Steve,

> *...cues are provided that identify different content types*

Hmmm... when I read this, I also started thinking about links to
alternative format materials (i.e. different content "types"). I have seen
(numerous times) CSS Style Sheets that query file extensions and then place
"icons" either before or after the link indicating (for example) that the
link goes to a PDF or Word Doc:

a[href$=".pdf"]

   { background-image: url(images/pdf-icon.png);

   background-position: center left;

   background-repeat: no-repeat;

   padding-left: 35px;

   height: 35px;

   display: inline-block;

   padding-top: 10px; }

​At first reading, this above snippet would satisfy a "cue" that is
identifying a content type (PDF) - at least visually, and I can see how
this would be a benefit for many users, including ​the COGA TF's primary
constituents. This is further suggested here:

Techniques

Symbols are available that help the user identify key content types
identified in a glossary section.

(I suspect that this could use some editorial assistance too, as it seems
there are two concepts here: that symbols can (should?) be used, and that
those symbols are 'defined' in a separate glossary section. Is that a
correct reading? I would suggest splitting it into two sentences if that is
the intent.)

Yet I am fairly confident this is not exactly what you are driving at or
to. Can you confirm or deny? (Thanks)

Also how does this fit with non-sighted users?
As well, while I've seen the above (or similar) CSS numerous times, there
is a huge potential that the above technique would likely fail SC 1.1.1
"All non-text content that is presented to the user has a text alternative
that serves the equivalent purpose" unless the content author also provided
a specific aria-label to the background icon (which just feels 'hacky' to
me). I suspect that there may also be some potential conflict here with
SC 1.3.3 Sensory Characteristics

*****

Reviewing the Git-hub page further, it notes:

Testability

Test Procedure


   1. Ensure, by inspection, that headings and regions are identified
      consistently.

and...

Automatic tests can include if:

<snip>

CSS is used consistently on headings, roles, personalization, and semantics.


...Wait, what?
​

By a close reading, it could be interpreted that *ALL*​ headings on a page
at the same level should look identical (identified consistently). Is this
suggesting that an h2 inside of the main element and an h2 inside the
footer element need to be the same size, color and font-face? If so, this
will be met with significant push-back from the larger design and
development world.

If, however, what you really mean is that all headings of the same level
should be styled identically (consistently?) within a containing *landmark
element* (all h2's inside of the main element across a collection of pages
are the same, etc.), and while h2's in the footer are styled differently
than those in the main element, that all h2's in the footer are also
identical
 across a collection of pages: that it is a peer to  peer relationship in
the landmark region that is important - if this is what the SC is driving
to, then I think we need more clarity around this (please).

*****

Finally, the Git-hub page states:

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.3 “Input Assistance”

If this is the case, then there is a serious disconnect between the testing
​ section (which speaks of headings and regions) and the larger Principle
​of "Input Assistance" which suggests it would be limited to (form) input
elements (ya?). I suspect this may simply be a "typo", and that, in fact,
this new proposed SC would more adroitly fit under:

​
*Guideline 3.2 Predictable: Make Web pages appear and operate in
predictable ways.*
​


​(* I put the word 'form' above in parenthisis, because now with
contenteditable <https://www.w3.org/TR/html5/editing.html#contenteditable>,
we can in fact have 'input' regions that are NOT part of a larger form
element.)​

If, however, it really is intended to be applied to "inputs" only, then
this is not being accurately captured in the current wording, sorry.

JF

On Thu, Feb 2, 2017 at 1:32 PM, Sailesh Panchang <sailesh.panchang@deque.com
> wrote:

> Does 'cue'  need to be defined?
> Does a  search button next to an unlabelled search textbox count as a
> cue in the context of this proposed  SC?
> Or only examples like:
> - The visual styling that  indicates  which tab is selected or  whick
> link in the left nav is  currently selected or which columnheader  is
> used for the current sort in a data table
> - Error indication: red border around failed fields on some pages and
> an error icon next   to others on  pages in the same collection
> - Marking up and styling submit / cancel elements for a form as
> buttons on some pages and links on others
> - Using a trashcan icon for Delete action and an 'X'  for the same
> action on a different page
>
> Even an h1 at start of main content on some pages and an h2 on others
> or using multiple h1 on some pages in a set makes it difficult to
> understand content organization. Does this count as a cue?
> Should 'cue' be substituted with 'presentation' ?
>
> The Benefits note, 'Providing consistent cues is a cornerstone of good
> UX design' and admit 'providing consistent cues is of benefit to all
> users'. Will this strengthen the  case for an accessibility related SC
>  or be countered with 'it will be covered in UI design for usability'?
>
> Thanks and regards,
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> Phone 703-225-0380 ext 105
> Mobile: 571-344-1765
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion