SCR19: This can cover onchange on checkbox / radio besides select controls

[spanchang]

SCR19 is limited to change of context caused by onchange on select controls.
In fact this technique can be enhanced to cover radio buttons and checkboxes that present conditional content based on onchange.
Also, should SC 2.4.3 and SC 1.3.2 be added as applicable SCs?
Thanks,
Sailesh

[joshueoconnor]

Adam, can you give us a rough ETA for a draft technique for this issue? Thanks

[adamsolomon]

if you want to add to the agenda for this week i can have it ready (the
proposal, not changes in the technique - Im assuming that before
corrections are proposed to the technique that the issue must be approved
and please correct me if i am wrong) within 6 hours of this email
otherwise will try and draft proposal in the issue within 3 days

On Sat, Aug 29, 2015 at 11:11 AM, joshueoconnor notifications@github.com
wrote:

Adam, can you give us a rough ETA for a draft technique for this issue?
Thanks

—
Reply to this email directly or view it on GitHub
#109 (comment).

[adamsolomon]

Proposed response:
Thank you for your comment.
This technique is indeed applicable to change events in both radio buttons and check boxes. Therefore, we will amend the technique to include two more examples. In addition, the word select in the procedure will be replaced by "user interface component", and the language of the procedure will be amended to reflect general scripting chaneges resulting from the onchange event, as opposed to a specific use case. The description will mention these three types of components specifically.

Regarding your suggestion to associate this technique with criteria 2.4.3 and 1.3.2, we feel that the technique is not in fact relevant to those criteria. Despite the description mentioning an important note that dynamic content changes triggered by the onchange event must be updated after the trigger element, this is a side issue. The main issue of the technique is the absence of a change in context resulting from the onchange event. This technique could very well include scripting examples which do not update actual content in the DOM, and which would therefore not be relevant to the aforementioned criteria.
In fact, after careful examination of the test procedure, we will amend that procedure to test for the absence of a change in context, and will remove the test for valid and correct updated content resulting from the onchange event, since the technique is not necessarily dependent upon dynamic content changes.

[joshueoconnor]

Ready for survey https://www.w3.org/2002/09/wbs/35422/charter_policy_update_2015/

[moekraft]

Hi Adam, can we add a link to the definition of change of context, http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef. I would add a link to the first match in the technique text. Thanks, Moe

[joshueoconnor]

[NEEDSINFO]
We need a pull request for what is there now in the technique - and what changes need to be made. We are leaving this open. Focusing on the test procedure rather than expanding this out to include other controls is preferable.

[joshueoconnor]

Sailesh, the working group agree that "This technique is indeed applicable to change events in both radio buttons and check boxes. Therefore, we will amend the technique to include two more examples. In addition, the word select in the procedure will be replaced by "user interface component", and the language of the procedure will be amended to reflect general scripting chaneges resulting from the onchange event, as opposed to a specific use case. The description will mention these three types of components specifically.

Regarding your suggestion to associate this technique with criteria 2.4.3 and 1.3.2, we feel that the technique is not in fact relevant to those criteria."

Do you want to update the technique and submit it as a pull request?

[adamsolomon]

Sorry Maureen, I just saw your request now. It must have slipped through.
Looking into this now

On Tue, Sep 15, 2015 at 6:07 PM, Maureen (Moe) Kraft <
notifications@github.com> wrote:

Hi Adam, can we add a link to the definition of change of context,
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef. I would
add a link to the first match in the technique text. Thanks, Moe

—
Reply to this email directly or view it on GitHub
#109 (comment).

[spanchang]

Josh / Adam,
The following statement in the technique's current description is quite significant for its successful usage:

"It is important to note that the select item which is modified is after the trigger select element in the reading order of the Web page. This ensures that
assistive technologies will pick up the change and users will encounter the new data when the modified element receives focus".
That's why I suggested referencing 2.4.3 / 1.3.2.
The test procedure also requires AT testing to verify that the changes to the associated element are recognized ... I suppose the reference is to correct focus order / reading order, is it not?
Thanks,
Sailesh

[awkawk]

I still agree with the WG's previous decision that this is not about 2.4.3 or 1.3.2. I would agree that almost everything is about 1.3.2 and 2.4.3 when you look at an example, but the focus of the technique is not these SCs.

I think that this technique was originally made because the select box with onChange was so commonly a problem. It is fine as it is, but it doesn't hurt to add the radio button situation as the procedure will be quite similar. Perhaps a separate technique is needed for the checkbox situation?

[spanchang]

Andrew,
Maybe the technique description and test procedure should be more clearer and convey what is really intended? Please see my Dec 01 comment that made me think that these SCs are covered too.
Thanks,
Sailesh

[WayneEDick]

I am only clear on my desire to see that radio buttons and check boxes are included and that is very clear in the technique.

[mraccess77]

I like the addition of radio buttons and checkboxes but do not support mapping to SC 1.3.2 and 2.4.3.

[awkawk]

Without new information we should regard assigning SCR19 to 1.3.2 and 2.4.3 as settled. The working group considered this question last year and decided that it did not agree.

[joshueoconnor]

@adamsolomon This could be made more generic as it is applicable to radio boxes.

[joshueoconnor]

@adamsolomon to create updated technique

[awkawk]

Preparing to mark as deferred due to inactivity and group resource constraints (https://www.w3.org/WAI/GL/wiki/Handling_Issues).

[spanchang]

Preparing to mark as deferred due to inactivity and group resource constraints
Inactivity: Was something expected of me? I raised the issue, wrote up
a technique specifically based on WG's request for a combined
technique.
Josh had commented that the response is generally positive and I also
addressed a few other concerns that had been raised.
In my humble opinion, as the WG has spent so much time on the topic,
perhaps it may be efficient to iron out the one or two remaining
issues and make a final decision.
Thanks,
Sailesh

On 4/12/16, Andrew Kirkpatrick notifications@github.com wrote:

Preparing to mark as deferred due to inactivity and group resource
constraints (https://www.w3.org/WAI/GL/wiki/Handling_Issues).

---

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#109 (comment)

[adamsolomon]

my bad. as i recall we basically had a consensus (as i remember though we should check the survey)
in any event i need to prepare a revised technique with the issues at hand which is based upon mine and sailesh's comments. so i will do that within the next week if the group so desires

[joshueoconnor]

That would be great @adamsolomon - thanks.

[alastc]

It appears the question of applying to other SCs is settled, there was just a task to update SCR19.

However, there are higher-priority techniques to do, so unless someone volunteers to do this, we'll close the issue in a few days.