Re: Informative components of w3c specifications

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

Received on Friday, 11 July 2014 19:25:48 UTC