Re: Informative components of w3c specifications

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

Received on Monday, 14 July 2014 00:11:18 UTC