Re: CfC: Pull Request 137

All,

While in principle I agree with this revision, and not wanting to stall
progress, I'm not 100% sure removing XHTML outright from this Technique is
useful in a broader context. If anything, I'd like to see this expanded to
note *all* W3C standardized markup languages, including SVG and MathML. The
current Technique states (plus I've added a proposed edit):

The objective of this technique is to use <strike>HTML and XHTML</strike>
<ins>W3C standardized mark-up languages</ins> according to their respective
specifications. Technology specifications define the meaning and proper
handling of features of the technology. Using those features in the manner
described by the specification ensures that user agents, including
assistive technologies, will be able to present representations of the
feature that are accurate to the author's intent and interoperable with
each other.


I will suggest that this possible edit enhances the technique, without
weakening or detracting from it.

Reading through the minutes of that January call
<https://www.w3.org/2016/01/12-wai-wcag-minutes.html#item06>, while there
was agreement at the end of the discussion, I also note Wayne's comment as
part of that exchange:

wayne: the xhtml is very important because of epubs groups that will be
looking to wcag. the extensions have to be compatible with xhtml.


Question: is this then worth re-opening? ePub is moving towards HTML5, but
we don't really say anything about SVG (which is a growing technology) and
perhaps we should, given that:

a) WCAG is (should be) technology agnostic, and,

b) this applies to both *4.1.1 Parsing** "In content implemented using
markup languages..."*, as well as *4.1.2 **Name, Role, Value* with the
Note: *"**This success criterion is primarily for Web authors who develop
or script their own user interface components."* (which one can do with
SVG, for example)

c) with a bit of a stretch we could also say that this applies to ARIA,
where if you DON'T use ARIA "according to their (it's) respective
specification(s)" you will again have content that may not be accessible
due to a "robustness" failure.


Thoughts?

JF

On Mon, Jun 6, 2016 at 10:33 AM, John Foliot <john.foliot@deque.com> wrote:

> +1 to these changes.
>
> JF
>
> On Mon, Jun 6, 2016 at 10:20 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
>> CALL FOR CONSENSUS – ends Wednesday June 8 at 11:30am Boston time.
>>
>> GitHub issue 133 (https://github.com/w3c/wcag/issues/133) was discussed
>> on a WG call as well as the proposed changes (in Pull request #137) and
>> were agreed to in a WG call (
>> http://www.w3.org/2016/01/12-wai-wcag-minutes.html#item06).
>>
>> Pull request:
>> https://github.com/w3c/wcag/pull/137/files?diff=split
>>
>> The changes are to update techniques H88 to be more focused on HTML5.
>>
>> If you have concerns about this proposed consensus position that have not
>> been discussed already and feel that those concerns result in you “not
>> being able to live with” this position, please let the group know before
>> the CfC deadline.
>>
>> Thanks,
>> AWK
>>
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility
>> Adobe
>>
>> akirkpat@adobe.com
>> http://twitter.com/awkawk
>> http://blogs.adobe.com/accessibility
>>
>
>
>
> --
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>



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

Advancing the mission of digital accessibility and inclusion