RE: Need Clarification on #170

Small correction for David’s comment:

“the <summary> element worked with screen readers and browsers even when the doctype was "HTML" (5)”

David means the “summary attribute”, not <summary> element, as this is new in HTML5 and works together with <details> (should be the first child element of details)

From: John Foliot [mailto:john.foliot@deque.com]
Sent: donderdag 11 januari 2018 19:21
To: David MacDonald <david100@sympatico.ca>
Cc: Makoto UEKI - Infoaxia, Inc. <makoto.ueki@gmail.com>; WCAG <w3c-wai-gl@w3.org>
Subject: Re: Need Clarification on #170

I agree with David - even if/when elements or attributes are deprecated, browsers rarely remove the functional support (I think maybe <marquee> and <blink> are the exceptions, but even there I am not sure...)

I know from numerous discussions with engineers attached to the various browsers (Moz, Chrome, Safari, etc.) that "breaking" older websites is something they all want to avoid at any cost, so they will rarely remove existing support, whether or not "HTML 5" has deprecated something or not.

JF

On Thu, Jan 11, 2018 at 9:59 AM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote:
Hi Makoto,

 just one thing about the idea of limiting applicability of techniques to specific version of HTML... even though an element or attribute may be deprecated in HTML that does not necessarily mean that it is not accessibility supported. Last time I checked, the <summary> element worked with screen readers and browsers even when the doctype was "HTML" (5)


Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902<tel:(613)%20235-4902>

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Wed, Jan 10, 2018 at 10:57 PM, Makoto UEKI - Infoaxia, Inc. <makoto.ueki@gmail.com<mailto:makoto.ueki@gmail.com>> wrote:
Hi David,

Thank you so much for your follow-up and comment on GitHub. I really
appreciate it.

I was participating in the working group during the discussions and
agree with you. I'm sharing the way of thinking about validation with
the commenter.

One of the possible solutions to address his concern would be indicate
the version of HTML in each technique document.

For example,
H73: Using the summary attribute of the table element to give an
overview of data tables
https://www.w3.org/TR/WCAG-TECHS/H73.html


It clearly indicate "HTML 4.01, XHTML 1.x" in its "Applicability"
section. Even if X attribute is obsolete in HTML5, the web page uses
HTML 4.01 and the X attribute is considered to be
accessibility-supported, then the web page can meet the SC.

We should focus on WCAG 2.1 for the time being. So I'll keep this
solution in mind.

Thanks again.

- Makoto


2018-01-11 4:56 GMT+09:00 David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>>:
> Hi Makoto
>
> The proposal in the issue was to ensure that pages validate to the spec
> declared on the page
>
> To help contribute some historical context to this. There was an incredibly
> difficult set of discussions around validation during WCAG 2.0. After many
> months of heated debate the Working group decided not to require full
> validation, but rather only a subset in 4.1.1 of validation errors that
> affect people with disabilities disproportionally. The reasons were as
> follows:
>
> Many/most validation errors don't disproportionally affect people with
> disabilities such as users of Assistive Technology.
> Validation is a time consuming and sometimes expensive exercise, and the
> group was concerned that it would burn up the accessibility budget on issues
> that don't affect people with disabilities.
> We have instead required only the following validation rules:
>
> elements have complete start and end tags,
> elements are nested according to their specifications,
> elements do not contain duplicate attributes,
> and any IDs are unique,
>
> We strongly support and encourage validation and list it as the first
> sufficient technique for 4.1.1
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-parses.html

>
> I'm guessing that these may be some of the reasons why this didn't find a
> champion to push it for consideration. We already considered it in 2.0, and
> there don't appear to be any new reasons to require validation. In recent
> years many sites don't validate, by design. And introducing this now would
> inhibit designs that may not be proved to have accessibility barriers.
>
>
> Cheers,
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902<tel:613.235.4902>
>
> LinkedIn
>
> twitter.com/davidmacd<http://twitter.com/davidmacd>
>
> GitHub
>
> www.Can-Adapt.com<http://www.Can-Adapt.com>
>
>
>
>   Adapting the web to all users
>
>             Including those with disabilities
>
> If you are not the intended recipient, please review our privacy policy
>
> On Wed, Jan 10, 2018 at 1:17 PM, Makoto UEKI - Infoaxia, Inc.
> <makoto.ueki@gmail.com<mailto:makoto.ueki@gmail.com>> wrote:
>>
>> Hi John,
>>
>> Thanks. Yes, I will. I'll keep conversation with him and think about it.
>>
>>
>> - Makoto
>>
>>
>>
>> 2018-01-11 0:45 GMT+09:00 John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>:
>> > Hi Makoto,
>> >
>> > Like all of the SC, they require a "champion" to stay on top of progress
>> > and
>> > ensure that the SC moves forward. If your colleague believes this is
>> > important, you might consider encouraging them to get more directly
>> > involved. After all, we'll likely start work on WCAG 2.2 later this
>> > summer...
>> >
>> > JF
>> >
>> > On Tue, Jan 9, 2018 at 9:51 PM, Makoto UEKI - Infoaxia, Inc.
>> > <makoto.ueki@gmail.com<mailto:makoto.ueki@gmail.com>> wrote:
>> >>
>> >> Andrew,
>> >>
>> >> Thank you so much for your response. I'll let him know the situation
>> >> the
>> >> WG had.
>> >>
>> >> Best regards,
>> >> Makoto
>> >>
>> >>
>> >>
>> >> 2018-01-10 0:53 GMT+09:00 Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>:
>> >> > Makoto,
>> >> > We had hoped to get to this, but with all of the other proposals no
>> >> > one
>> >> > moved this one forward so it didn’t get adopted. We have ideas that
>> >> > were
>> >> > raised well before this one, but if the WG wasn’t able to agree that
>> >> > it was
>> >> > ready to move into the editor’s draft by August 22 then they were not
>> >> > able
>> >> > to get into WCAG 2.1.
>> >> >
>> >> > Thanks,
>> >> > AWK
>> >> >
>> >> > Andrew Kirkpatrick
>> >> > Group Product Manager, Accessibility
>> >> > Adobe
>> >> >
>> >> > akirkpat@adobe.com<mailto:akirkpat@adobe.com>
>> >> > http://twitter.com/awkawk

>> >> >
>> >> > On 1/9/18, 10:47, "Makoto UEKI - Infoaxia, Inc."
>> >> > <makoto.ueki@gmail.com<mailto:makoto.ueki@gmail.com>>
>> >> > wrote:
>> >> >
>> >> >     Dear Andrew and Joshue,
>> >> >
>> >> >     There was a proposed SC which was presented on 23 Mar 2017. I
>> >> > happend
>> >> >     to find this #170 a few weeks ago.
>> >> >
>> >> >     New SC proposal: Harmonization with other newer specifications
>> >> > #170
>> >> >
>> >> >
>> >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F170&data=02%7C01%7Cakirkpat%40adobe.com%7C152d65969e83420f36ea08d557785064%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636511096619710193&sdata=uLgLTT3ZXboOC4vBinOsJPB51XcJs1Cz968E0tzcQW8%3D&reserved=0

>> >> >
>> >> >     This proposal was not accepted. I'd like to confirm the reason.
>> >> >
>> >> >     The reason was desribed on GitHub saying that "it hasn't been
>> >> > adopted
>> >> >     by the Working Group in time for the August 22 deadline for new
>> >> > SC
>> >> > in
>> >> >     WCAG 2.1 so we are deferring it for consideration in future
>> >> > releases."
>> >> >
>> >> >     This explanation is not acceptable because he made the proposal
>> >> > in
>> >> >     March. It means the working group had six months. Was it simply
>> >> > due
>> >> > to
>> >> >     the schedule?
>> >> >
>> >> >     I think that the working group should explain the reason why the
>> >> >     proposed SC was not adopted in more detail so that he can
>> >> > understand
>> >> >     it. He didn't satisfied with the response from the working group
>> >> > and
>> >> >     still remains unconvinced.
>> >> >
>> >> >     Could you please clarify the reason for him? Thank you in advance
>> >> > for your time.
>> >> >
>> >> >
>> >> >     Best regards,
>> >> >     Makoto
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > John Foliot
>> > Principal Accessibility Strategist
>> > Deque Systems Inc.
>> > john.foliot@deque.com<mailto:john.foliot@deque.com>
>> >
>> > Advancing the mission of digital accessibility and inclusion
>>
>>
>>




--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------