Re: Informative components of w3c specifications

And by Mark I of course mean Marcos. Damn autocorrect.
On Jul 11, 2014 7:46 PM, "Shane McCarron" <shane@aptest.com> wrote:

> I think what mark was reacting to was the suggestion that we also add text
> to the header:  Note (informative)
>
> I don't think anyone has objected to the concept of ensuring informative
> portions of documents are wrapped in an element that correctly indicates
> that state to people who are using assistive technology.
>
> Maybe I missed something.
>  On Jul 11, 2014 2:25 PM, "Mark Sadecki" <mark@w3.org> wrote:
>
>> On 7/11/14, 11:57 AM, Marcos Caceres wrote:
>> >
>> >
>> > On Friday, July 11, 2014 at 10:53 AM, Shane McCarron wrote:
>> >
>> >> Marcos, I do *not* disagree with you, but your statement reminded me
>> of one of my very early experiences in the standards world. I share it for
>> your amusement, but it may also change your mind.
>> >>
>> >> I was working on X3J11 (ANSI C) in about 1986?
>> > Much respect.
>> >> In reviewing a draft, there was some language that was overly complex
>> and honestly unclear. I'm a smart guy and a native English speaker, so I
>> finally puzzled it out. But non-native speakers or people who can't readily
>> parse a 100 word sentence might have trouble. I proposed a change to
>> basically split up the sentence and remove some punctuation so there were
>> fewer dependent clauses.
>> >>
>> >> A few months later, when the committee was done processing all of the
>> change requests, the reply I got was along the lines of "Thank you for your
>> comment. Your proposed change is rejected. A complete reading of the
>> standard would render full understanding of this issue".
>> >>
>> >> In other words, if I read the entire document, I would have known what
>> that section meant. I didn't need to be reworded.
>>
>> Thanks for the apropos anecdote, Shane.  It makes a very good point.
>> > That's very sad to hear. The committee were either incompetent or
>> lacked judgement when rejecting your change (specially if it helped clarify
>> things).
>> >
>> > However, your change was still to normative text. And although I take
>> your point about not needing to backtrack to know what is informative and
>> what is normative, this still doesn't strengthen (in my mind, at least) the
>> need to add "this is informative" explicitly on a note.
>> >> People don't read the entire document. Other documents link into our
>> specs - to sections that have normative text and embedded notes. I am as
>> lazy as the next guy. I am not going to scroll up to the conformance
>> section to see whether notes are by default informative in the spec I am
>> reading at the moment. I'm just not.
>> >
>> > Personally, I'm still not convinced that this is an issue. Unlike other
>> consortia, we have a strong culture of being very developer focused.
>> Hi Marcos, I would like to hear you elaborate on how being developer
>> focused
>> absolves us from clearly delineating normative and non-normative text,
>> specifically for users of assistive technology.
>> >
>> > My gut reaction here is that I sometimes feel like we are trying to
>> "fix" things preemptively without data to show there is actually a problem.
>>
>> This discussion began when I attempted to address point 3 in the Editorial
>> Comments section of Jim Allen's comment [1] on the HTML5 Image Description
>> Extension, specifically:
>>
>> "The problem with graphical formatting is that the blocks starting
>> with "This section is informative" are indented and have a differently
>> colored background, but there is nothing textual to denote where the
>> block ends."
>>
>> From a screen reader users perspective, it is unclear when a block of
>> text that
>> is solely distinguished with visual formatting begins and/or ends.  I was
>> not
>> requesting that we add bloat to the rendered text.  I was proposing that
>> we add
>> two additional attributes, a role, and an aria-label.  I hardly think
>> this is
>> adding any hardship to the editor, who only needs to add a
>> ```class=note```
>> (which they presumably are already doing) to the <div>, respec does the
>> rest.
>> What this does is it creates an experience for the screen reader user that
>> clearly announces what the role of the block is, when it begins and when
>> it
>> ends.  I was not requesting that additional text be rendered to the page.
>>
>> Best,
>>
>> Mark
>>
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-html-a11y/2014Jan/0068.html
>> >
>>
>>
>> --
>> Mark Sadecki
>> Web Accessibility Engineer
>> World Wide Web Consortium, Web Accessibility Initiative
>> Telephone: +1.617.715.4017
>> Email: mark@w3.org
>> Web: http://w3.org/People/mark
>>
>