Re: Need Clarification on #170

Hi David,

>  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.

Exactly. That is the point and I shared it with the commenter.

Thanks!
Makoto



2018-01-12 20:35 GMT+09:00 David MacDonald <david100@sympatico.ca>:
> no I'm talking about the summary attribute on the <table> element
>
> https://www.w3schools.com/tags/att_table_summary.asp
>
>
> Cheers,
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902
>
> LinkedIn
>
> twitter.com/davidmacd
>
> GitHub
>
> 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 Fri, Jan 12, 2018 at 3:27 AM, Abma, J.D. (Jake) <Jake.Abma@ing.nl> wrote:
>>
>> 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>
>> 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
>>
>> LinkedIn
>>
>> twitter.com/davidmacd
>>
>> GitHub
>>
>> 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 10:57 PM, Makoto UEKI - Infoaxia, Inc.
>> <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>:
>> > 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
>> >
>> > LinkedIn
>> >
>> > twitter.com/davidmacd
>> >
>> > GitHub
>> >
>> > 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> 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>:
>> >> > 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> 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>:
>> >> >> > 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
>> >> >> > http://twitter.com/awkawk
>> >> >> >
>> >> >> > On 1/9/18, 10:47, "Makoto UEKI - Infoaxia, Inc."
>> >> >> > <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
>> >> >
>> >> > Advancing the mission of digital accessibility and inclusion
>> >>
>> >>
>> >>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> John Foliot
>>
>> Principal Accessibility Strategist
>>
>> Deque Systems Inc.
>>
>> 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.
>> -----------------------------------------------------------------
>
>

Received on Friday, 12 January 2018 12:55:32 UTC