RE: Proposal for 1.3, "Ensure that information, functionality, and structure are separable from presentation"

Hi Joe,

Thanks for all your work on this.
My replies/answers are marked GV without *'s and >'s in front of them

 


> This means use (X)HTML, basically. It could also mean tagged PDF. I
> have a technique in mind for plain-text documents that we could talk
> about later.
>
> ** GV:  If there is to be a limitation - it must be reflected in SCs or
JPEG will be covered.

JOE: 
No, that represents a misunderstanding of the data formats in use on the 
Web.


GV:  I don't understand your comment here.  I was talking about the standard
rather than data formats.  The SC should reflect the guideline.  If all the
SC are intended to inherit a limiting provision - it must be stated in each
SC so they can stand independently for conformance testing.   When you
clipped the above text out of the original email you cut off the first part
so it is hard to see what I mean without going back to the original post.
But if you do, you will see that the intended limitation isn't included in
the wording of each SC - and I think you meant for it to apply.   So I was
just saying that if you want the "if such and such is true" to apply to each
SC, then you need to put it in the SCs - you can't rely on its being in the
guideline to carry it over to the SCs.   That's all. 



> So now that you're using (X)HTML or tagged PDF, you have to use the
> correct element for whatever you're encoding (*within reason*; there
> will always be exceptional cases where authors must approximate).
> This handily takes care of the obsession with emphasis found in
> previous versions.
>
>
>> ** GV:  To the extent possible needs to be made objective.

JOE:
No, it does not. The semantics of HTML coding are expressed, sometimes 
quite imperfectly, in HTML specs. Competent authors agree most of the 
time. The rest of the time, it is up to the author to approximate.

This is not a machine-testable outcome and never can be. If you want to 
use the 80%-inter-rating rule, fine.


GV:  By being more objective - I was referring to the 80% IRR.  I didn't
mention anything about machine testing - and we don't require it anywhere in
the guidelines - though it is nice when it is possible.   "to the extent
possible" is not generally considered objective enough to meet the 80% rule.
That is all. 






> ** GV: this looks like part of the 4.2 discussion.  What if there is no
> accessibility features available.  Can I use the technology and just not
> have it accessible?

Which exact technologies are you talking about?

GV: See above.  I am talking about new technologies (like PDF, flash, etc.)
that continually come into being.     





> 	Level 2 success criterion
>
> 	Only markup languages and technologies that enable
> 	separation of structure, presentation, and behaviour are
> 	used.
[...]

> ** GV:   Ah here it is.   Hmmmm. I don't think we should do this.  But we
> should require alternate presentation if it is not possible with the
> technology talked about.

I don't understand the objection.

GV: Ok.  Couple of example problems with it would be  
1) the proposed SC outlaws text.  (we may want to do this but I'm not sure.)

2) an author should be able to use whatever an author wants, including
technologies that are accessibility opaque (completely inaccessible), as
long as they also provide the information and functionality in an accessible
fashion as well.  Again - not as good - but possible.

Maybe this could be a level 3 SC and be ok.  But I'm afraid it might outlaw
some newer technologies at level 2.   Would be a good topic for discussion. 
 


Gregg wrote:
> Plain text though is a question. Is it structure we are trying to preserve
> or is it information we are trying to not lose?  That is the discussion
> point.

JOE:
It's a discussion point for people who don't accept that we're already 
making Web *content* accessibility guidelines, admittedly, yes.

If you run a Web site with nice valid code and somebody hands you a 25K 
plain-text file you want to post, you shouldn't have to spend an hour of 
your life you'll never get back turning that into HTML. You should just be 
able to post it.

If your photo-gallery page has alt texts on the thumbnails that, when 
clicked, show you nothing but the larger image with no surrounding HTML, 
you should not have to custom-write some kind of content-management system 
to enclose those larger images in an alt text you will already have had a 
chance to read.


GV: I don't understand  your comments here Joe.  I was agreeing with your
observation on plain text; - and that although plain text seemed to violate
the rules it also looks like plain text should be acceptable (at least at
level 1 or 2).   So I was questioning some of the precepts that would make
plain text fail.  Do we want plain text to fail at level 2 - and require all
plain text docs to be converted?  I didn't think so - and you don't either I
gather.  But the criterion would seem to imply this.   

Regarding your comments about photos - I didn't mention anything about
photos.  And I am not sure what photos have to do with plain text docs
failing.  (though I would agree with your analysis of the problem you posed)




And from the beginning of the post.

> **GV:   Good points.   Does this give a blank check though to technologies
> that could but don't bother to allow this

JOE:
Like what? SVG?
I think the objection is not significant.


GV:  Again, the text I was commenting on was cut off so it is hard to follow
this but the part I was commenting on dealt with adding the phrase " any
access features present" to the provision.  This would mean that authors
would only have to worry about the provision if the source technology had
accessibility features in it. If it did not - then the author could ignore
the provision because they would automatically conform.   

We found that when writing guidelines - especially technology independent
ones, we need to choose wording carefully.    To date, technologies like PDF
have worked to build in access because they had to in order to pass
accessibility provisions.  If we rewrite them to say that authors work would
pass as 'accessible' at some level if they use "any access features present"
-- then it is in fact easier to conform to this guideline if you choose a
technology that doesn't have provisions for this than if you do.   

If the problem is important enough for us to include a requirement that it
be solved - then I was saying that using a technology that doesn't address
the problem - shouldn't result in a decision that the need was met.  

This approach would also result in much lower incentive to technology
developers to build access provisions into the technologies.   If it is in
fact easier for authors to pass a particular SC if the technology they
choose doesn't have provisions - then why would they ask for that to be
added to the technology - (since it would just mean that they had to do more
work to conform). 

That's all I was saying.   A side thought is that if we feel that some of
our provisions should be drop-able if the technology doesn't support them -
then maybe we should be dropping them for everyone - or putting them at
level 3. 


Again - thanks for all your work on this Joe.   Lots of good ideas in your
compilation.   And it raised lots of other things that were not obvious that
we need to think about and decide as a group. 

Gregg
  


--

Received on Sunday, 1 May 2005 14:00:29 UTC