Re: should we say "critical controls" or just "controls".

> *Here is the question: should we say "critical controls" or just
"controls"?*

Just "controls", as it then leaves the subjectivity out or the equation - I
don't have to try and guess what is and isn't critical (and again, what is
critical to me may not be critical to you, or vice-versa).

While we on the call and watching this thread have a pretty good idea of
what you are alluding to, I again struggle with making that determination
of what is or isn't "extra", "critical" or "essential" - as James Nurthen
stated very few web apps or sites just add stuff because it's stuff - it
has been added because somebody felt it was important / critical enough to
add in the first place.

I have to say Lisa that the way this SC is advancing, I do not personally
think it will solve the problem(s) you are seeking to solve here. Stay with
me...


The current draft calls for "*contextual information for regions and
 [critical ] controls is programmatically determined."*

I'll will once again return to the menu element
<https://www.w3.org/TR/html51/interactive-elements.html#the-menu-element>,
and illustrate my issue with a code example that was provided in an earlier
HTML5 draft
<https://dev.w3.org/html5/spec-preview/the-menu-element.html#the-menu-element>
:

<menu type="toolbar"> *<<- @type provides the programmatic
determination and context in the Accessibility API*
 <li>
  <menu label="File"> *<<- @label provides the programmatic
determintion and context*

   <button type="button" onclick="fnew()">New...</button>  *<<- the
text value ("New") of <button> provides the programmatic determination
& accessible name for that button*

   <button type="button" onclick="fopen()">Open...</button>
   <button type="button" onclick="fsave()">Save</button>
   <button type="button" onclick="fsaveas()">Save as...</button>
  </menu>
 </li>
          <<SNIP>>
</menu>

Some questions:

   1. would you agree that the code sample above meets the
   ​ requirements​
   language you are proposing?
   ​That the programmatic associations are present?​ For the "whole" menu,
   the sub-menu, and the buttons in that sub-menu?


   I have shown where the programmatic association exists, and I will even
   go so far as to agree that these (example) buttons are all 'critical' to
   the functionality of the associated widget  (certainly "New", "Open",
   "Save", and "Save As" are all equally important in different contexts,
   correct?)

   2. ​How does that code example specifically benefit the target
   user-group to the point that we are now mandating what is already mostly
   Best Practice and procedure? That's an honest and serious question.

   Is there AT today that leverages that programmatic determination in a
   fashion that benefits users with different types of cognition issues? ​As
   an accessibility evaluator and instructor, how do I "up-sell" this as a
   specific solution, rather than just a good idea?



​> The point is you do not need to add contextual information to things
that you are sure are extra.

Again Lisa, as a 3rd-Party evaluator I cannot be put in a position where I
have to determine​ what is or isn't "extra" for individual users.

Most web-site *users* would likely say that "ads" are always "extra" and
not needed (and given the popularity of the different ad-blockers out
there, I think that is a fair assessment), but the *site and content owner*
may disagree (and that's not just a hypothetical, try visiting a site like
The Guardian or The Washington Post with an ad-blocker turned on).

When the content owner and the content consumer have differing
perspectives, we cannot get in the middle of that by "picking sides". A new
Success Criteria that has the net effect of forbidding sites to refuse to
expose content because the end-user is using an ad-blocker (and thus
impacting their revenue stream of that content owner) simply won't fly - it
will be ignored and not acted upon, which not only does not solve the
problem, but also has a potential cumulative effect of weakening all of
WCAG.



​Candidly and honestly, this proposed SC very much feels like it is written
mostly to provide a "hook" to advance COGA Semantics - that this new SC
will ultimately create the demand for that spec. I get that, and this
really is a chicken and egg problem (how to create the demand for that
draft spec when it doesn't exist today, even though the problem being
solved is very real).

But with the second bullet point and my code example above, I cannot see
how this achieves the larger goal. I have shown that by doing nothing but
use the <menu> element as advised in the HTML spec, I have provided the
"programmatic association" that the draft second bullet-point requires, but
still not solved the end-user problem that is driving this current SC in
the first place.

At that point, I honestly have to ask, are we really approaching this the
right way? I am not convinced we are.

JF


On Tue, Jun 27, 2017 at 1:35 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> Hi folks
>
> the wording for personilazation (issue 6) that we seem to be moving
> towards is:
>
>  *For pages that contains interactive controls or with more then one
> regions, one of the following is true:  *
>
>    - * a mechanism is available for personalization of content that
>    enables the user to add symbols to interactive controls OR*
>    - *  contextual information for regions and  [critical ] controls is
>    programmatically determined. *
>
>
> where critical controls  could be defined something like:  *controls that
> are essential for the task that a user may have come to the page for*
> (see issue 6 for other definitions)
>
> *Here is the question: should we say "critical controls" or just
> "controls"?*
>
> The advantage of saying "critical controls" is it limits the amount of
> work that the author has to do. so you only need to add sematics to some
> controls (of course you do not have to add any with option 1)
>
> The disadvantage is there is a bit of a judgment call on what is a
> critical control. Note that we are not asking you to identify that they are
> critical control or not, just to add contextual information to them. So if
> you are not sure you can always just add the contextual information. The
> point is you do not need to add contextual information to things that you
> are sure are extra. (it is a more limited usage then the the "core" was
> used in the last version.)
>
> So for example, on a page to compose an email, the send button would be
> critical, but undo button or format buttons would not be critical. If you
> had an app for businesses with different buttons for different types of
> employees they would all be critical. if you are not sure you would never
> be at fault for adding more contextual information, you would just be doing
> more then the minimum. We could also add a lot of examples in the
> understanding document to help. I would prefer to leave it in but I do not
> want to lose the SC just to help authors do less work.
>
> Which do you prefer?
>
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>


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

Advancing the mission of digital accessibility and inclusion