Re: Informative components of w3c specifications

Good point.
On Jul 13, 2014 7:11 PM, "Mark Sadecki" <mark@w3.org> wrote:

> On 7/11/14, 8:46 PM, Shane McCarron wrote:
> > I think what mark was reacting to was the suggestion that we also add
> text to
> > the header:  Note (informative)
>
> I see.  Well, since its not inserted manually by the editor, there is no
> hardship associated with it.  I see no harm in clearing indicating the
> non-normative nature of the content, especially for those who may have
> arrived
> via an fragment link, be they developers or not.
>
> Best,
>
> Mark
> >
> > 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 <mailto: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 <tel:%2B1.617.715.4017>
> >     Email: mark@w3.org <mailto:mark@w3.org>
> >     Web: http://w3.org/People/mark
> >
>
>
> --
> 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
>