- From: Peter Korn <peter.korn@oracle.com>
- Date: Tue, 11 Sep 2012 15:21:48 -0700
- To: Gregg Vanderheiden <ez1testing@gmail.com>
- CC: "Hoffman, Allen" <Allen.Hoffman@HQ.DHS.GOV>, Alex Li <alli@microsoft.com>, Loďc Martínez Normand <loic@fi.upm.es>, Gregg Vanderheiden <gv@trace.wisc.edu>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
- Message-ID: <504FB97C.2000506@oracle.com>
Gregg,
Follow up comment: While the two examples you found were quite helpful
(for me at least) in tackling this SC, I wouldn't include those specific
examples in the actual WCAG2ICT text. I think we should either create
our own examples that would then be hosted on the W3C website and that
DO have good filenames that are sufficiently descriptive; or simply not
have any examples in the actual WCAG2ICT text.
Peter
On 9/11/2012 3:16 PM, Peter Korn wrote:
> Gregg,
>
> Looking at proposal #10, I think we are almost there. I would like to
> see us use language parallel to what is in SC 2.4.2 for software,
> namely the sentence fragment from the sentence (emphasis added):
> "However, since there is almost always a single user interface
> component associated with top-most explicit groupings of user
> interface components (things like "windows", "dialog boxes", "frames",
> and "screens"), and since 4.1.2 requires that every user interface
> component has a programmatically determined name, /*conforming to
> 4.1.2 would thereby mean that this success criterion was met if the
> name for the user interface component associated with top-most
> explicit groupings of user interface components described its topic or
> purpose*/."
>
> Applying this to your proposal #10, the final note #6 would then
> become (/*additions emphasized*/):
>
> Authors can assume that an infrastructure exists that allows users
> to locate documents in the set; for example, by selecting links
> within a member document, browsing through the files that make up
> the set, or by searching the documents' contents or the names of
> the member documents, since document names and the ability for
> machine access to the text are required by other success criteria.
> *Therefore conforming to SC 2.4.2 would thereby mean that this
> success criterion was met.*
>
>
>
> Regards,
>
> Peter
>
> On 9/11/2012 3:08 PM, Gregg Vanderheiden wrote:
>> Well it does apply. And if people did NOT name the files in a clear
>> way or have links in the docs (one or the other) then it would not
>> meet this SC. So it applies and is important. It just is not a
>> problem if you take the fairly simple (but not always done) step of
>> naming the file so that you can find the parts.
>>
>> As you point out, we are not charged with or authorized to tell the
>> Access Board or M376 or anyone else what rules should or should not
>> be applied. We were only charged with explaining how it would be
>> applied.
>>
>> Since naming the file something logical is easy and also meets both
>> this and the TITLE success criterion I'm not sure why we are spending
>> all this time on this.
>>
>> There is something that is important to be done. Doing it is easy and
>> meets at least two success criteria.
>>
>> Peter, all, there is now a proposal that includes the info from the
>> discussion today and I think makes it clear. Here I wish we could
>> just say "one way of meeting this is" but that gets us into
>> techniques land. So I tried to do everything I could. Give it a
>> read and see what you think.
>>
>> Gregg
>>
>>
>>
>> On Sep 11, 2012, at 4:53 PM, "Hoffman, Allen"
>> <Allen.Hoffman@HQ.DHS.GOV <mailto:Allen.Hoffman@HQ.DHS.GOV>> wrote:
>>
>>> Mostly we are working this because we were not given the option of
>>> recognizing that sometimes an SC doesn't apply in a particular
>>> environment true or not.
>>> *From:*Alex Li [mailto:alli@microsoft.com <http://microsoft.com>]
>>> *Sent:*Tuesday, September 11, 2012 5:49 PM
>>> *To:*Peter Korn; Hoffman, Allen
>>> *Cc:*Gregg Vanderheiden; Loďc Martínez Normand; Gregg Vanderheiden;
>>> public-wcag2ict-tf@w3.org <mailto:public-wcag2ict-tf@w3.org>
>>> *Subject:*RE: examples of sets of documents
>>> Despite the fact that we still don’t have adequate clarity on how
>>> this SC works in the context of documents, we all seem to be saying
>>> that this is trivial. If so, why are we wasting so much time trying
>>> to preserve a trivial SC? Should we put our effort into casting the
>>> SC out instead of wasting more time trying make it work? I’m open
>>> to a note per Peter’s suggestion or deleting the SC in the context
>>> of documents.
>>> *From:*Peter Korn [mailto:peter.korn@oracle.com]
>>> *Sent:*Tuesday, September 11, 2012 2:36 PM
>>> *To:*Hoffman, Allen
>>> *Cc:*Gregg Vanderheiden; Loďc Martínez Normand; Gregg
>>> Vanderheiden;public-wcag2ict-tf@w3.org
>>> <mailto:public-wcag2ict-tf@w3.org>
>>> *Subject:*Re: examples of sets of documents
>>> Allen, gang,
>>>
>>> In addition to the two NOTEs that Gregg has proposed in this thread,
>>> why not also make this really easy for folks - assuming it is so
>>> trivial to meet in the desktop GUIs of today - by adding a third
>>> NOTE that makes that abundantly clear. Let's not waste developers'
>>> (and procurers') time & brainpower to walk through the various steps
>>> in order to conclude that this is trivially / automatically met;
>>> let's spell that out clearly (perhaps similarly to what we [tried
>>> to] did with AccessibleName for top-level frame as a way to meet SC
>>> 2.4.2).
>>>
>>>
>>> Peter
>>>
>>> On 9/11/2012 5:01 AM, Hoffman, Allen wrote:
>>>
>>> I agree with all Peter’s points here.
>>> If this just becomes trivial to meet but is not really
>>> procedurally and/or culturally normative to just say this makes
>>> little sense to apply in this context, then as long as we
>>> clearly state these conditions I can live with that.
>>> *From:*Peter Korn [mailto:peter.korn@oracle.com]
>>> *Sent:*Tuesday, September 11, 2012 2:16 AM
>>> *To:*Gregg Vanderheiden
>>> *Cc:*Loďc Martínez Normand; Gregg
>>> Vanderheiden;public-wcag2ict-tf@w3.org
>>> <mailto:public-wcag2ict-tf@w3.org>
>>> *Subject:*Re: examples of sets of documents
>>>
>>> Gregg,
>>>
>>> Comments in-line below:
>>>
>>> On 9/10/2012 9:51 PM, Gregg Vanderheiden wrote:
>>>
>>> Peter, Loic,
>>> You were having trouble seeing how these could meet the SC
>>> 1) these are on the web so the question is would they meet
>>> WCAG -- And the answer is yes. Browsing and searching.
>>>
>>>
>>> PK: Neither browsing nor searching work JUST FROM THE TWO (pairs
>>> of) URLs YOU DISTRIBUTED TO US. They might be on a website with
>>> either a search function and the ability to browse, but we
>>> didn't see that. Therefore, given what we had (e.g. a "web
>>> site" consisting of only two URLs), I still maintain that they
>>> as such didn't meet WCAG.
>>>
>>> 2) if they were NOT on the web - the question isn't whether they
>>> DO or not but whether they easily could or not.
>>>
>>>
>>> PK: I'm sorry, I misunderstood your reply.
>>>
>>> 2a) another question (ala Alan) is whether they could meet the
>>> SC WITHOUT having to open them up and re-edit them.
>>> The answer to (2) and (2a) is yes for both.
>>> Walking this through.....
>>> Assuming you are distributing these in some fashion besides the web.
>>>
>>> * If on the web then use WCAG directly.
>>> * If a person downloads them from the web then -- all bets are
>>> off. WCAG doesn’t cover that we we don't either. It was on
>>> the web and met WCAG. If the user choses to pull it into
>>> another environment -- then the author is not responsible
>>> any more than if they broke them apart or printed them as
>>> image documents to their drive or anything else.
>>>
>>> So - back to assuming you are distributing them in some way
>>> other than the web. You are distributing one of these sets on a
>>> flash drive or dvd or zipped and mailed to someone or on a file
>>> servers or in some other non-web fashion.
>>> Since you are doing so, you would, should, (or at any rate -
>>> easily can), give them a meaningful file name before you
>>> distribute them.
>>> This will allow you to meet SC 2.4.2. Page Title
>>>
>>>
>>> PK: Note: that shouldn't be the ONLY way to meet SC 2.4.2.
>>>
>>> It also give you (or rather, you give the user) two simple
>>> methods which would meet SC 2.4.5.
>>> 1) the user can browse to them in the Finder or Windows Explorer.
>>> 2) the user can use the search function in the Finder or Windows
>>> Explorer.
>>> Both techniques are ways the user can use to find the documents.
>>>
>>>
>>> PK: I still don't follow. Let us say they have meaningful
>>> filenames, but neither document refers to the other. Are you
>>> saying that, given a "modern" desktop OS that allows searching
>>> by filename and browsing contents of disks/directories, that SC
>>> 2.4.5 should essentially automatically be met?
>>>
>>>
>>>
>>> The directory method (#1 above) is a direct parallel with
>>> technique*/G63 "providing a site map"/*since the directory
>>> provides a listing of all of the parts of the set.
>>>
>>>
>>> PK: For this to be used by folks in meeting SC 2.4.5, I believe
>>> we need a NOTE or other text to direct folks to the non-web
>>> equivalent of "providing a site map".
>>>
>>> The search function (#2 above) is a direct parallel with*/G161
>>> "Providing a search function to help users find content."/*
>>>
>>>
>>> PK: Ditto here - this should be made clear in our guidance for
>>> non-web ICT software if we are to expect folks to use it.
>>>
>>> If the docs meets the other success criteria then these two
>>> approaches would work and would do it.
>>> If the docs do not meet the other success criteria (e.g. they
>>> don't have meaningful titles when you pass them around to
>>> others, or are not text ) then they don't conform anyway.
>>> So you can easily meet this success criterion without editing
>>> the document at all.
>>> And if you want to keep the document number (if it has meaning)
>>> you can do that too. (e.e. "document name - 56013d01.pdf"
>>>
>>>
>>> PK: Finally, making this essentially trivial to meet (meet SC
>>> 2.4.2 & exist on a modern desktop OS and you have automatically
>>> met SC 2.4.5) I think strips it of nearly all of its meaning and
>>> value.
>>>
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> Gregg
>>> On Sep 10, 2012, at 4:54 PM, Loďc Martínez Normand
>>> <loic@fi.upm.es <mailto:loic@fi.upm.es>> wrote:
>>>
>>> Dear all,
>>> Thank you Gregg for providing these good examples of sets of
>>> documents, which I agree they are.
>>> But I'm with Peter about conforming to 2.4.5 (multiple ways). I
>>> don't think that there two examples meet 2.4.5 either as web
>>> content or as a set of documents once downloaded in one
>>> computer. I don't think that the techniques defined for 2.4.5
>>> are applied in those two examples.
>>> Best regards,
>>>
>>> Loďc
>>>
>>> On Mon, Sep 10, 2012 at 11:16 PM, Peter Korn
>>> <peter.korn@oracle.com <mailto:peter.korn@oracle.com>> wrote:
>>>
>>> Hi Gregg,
>>>
>>> I'm afraid I don't see how these example documents meet 2.4.5
>>> Multiple Ways - either using Proposal #9
>>> athttps://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-waysor
>>> frankly just as web pages using WCAG 2.0.
>>>
>>> In the Muse Test Suite example, the filenames are
>>> "MUSE_DTF4.1p_V07.pdf" and "MUSE_DTF4.2p_V05.pdf" (or perhaps
>>> "6BED1d01.pdf" and "57013d01.pdf" as that is what they get as
>>> temporary filenames when passed to my copy of Adobe Reader).
>>> Neither of these are "Test Suite, Part 1: Test Objectives" or
>>> "Test Suite, Part 2: Test Methods" - so internal references to
>>> those filenames don't exist (so I don't see how that would be
>>> "one of the multiple ways"). This same situation arises with
>>> the Audacity example - the filesystem filenames don't match the
>>> document filenames ("Super-Fast Guide to Audio Editing" vs.
>>> "Audacity_Guide.pdf" and "Editing Audio with Audacity (Part
>>> 2)" vs. "EditingAudioPart2.pdf").
>>>
>>> Also, proposal #9 lacks the NOTE at the end of proposal #8, but
>>> even following that NOTE, since not all documents in both
>>> examples contain links to the other, the only "way" of the
>>> necessary at least 2 ways that I find is "searching the
>>> documents' contents").
>>>
>>>
>>> So... while I think these are good examples of a "set of
>>> documents" - at least for purposes of our discussion - I don't
>>> see them as examples of documents that pass our contemplated
>>> tests for 2.4.5 (let alone passing WCAG 2.4.5 when viewing them
>>> as web pages).
>>>
>>>
>>> Peter
>>>
>>> On 9/8/2012 2:52 PM, Gregg Vanderheiden wrote:
>>>
>>> Hi Peter,
>>> Currently they are web pages. And the do meet WCAG as web
>>> pages.
>>> I can't comment on their meeting WCAG in other contexts since
>>> a) the other context is not described
>>> b) the WCAG2ICT hasn’t said how WCAG would be applied to
>>> those other contexts.
>>> Given the discussions we have been having in WCAG2ICT though
>>> -- I would see no problem in the documents meeting what the
>>> WCAG2ICT has been discussing, and doing so in most any
>>> context that I can think of (e.g. saved from an email, on a
>>> server, in a folder together on a drive, of flash memory
>>> stick, etc.) except if you split them up -- but we
>>> specifically exclude a set that has been broken up from
>>> being still considered a set -- so I guess they would pass
>>> that too.
>>> /Gregg/
>>> --------------------------------------------------------
>>>
>>> On Sep 7, 2012, at 12:28 PM, Peter Korn
>>> <peter.korn@oracle.com <mailto:peter.korn@oracle.com>> wrote:
>>>
>>> Gregg,
>>>
>>> Thanks for finding these examples!
>>>
>>> Looking at the first set (Muse Test Suite), in your opinion
>>> should these pass or fail the SC? In your reading of the
>>> draft SC language, do they pass or fail? Any why?
>>>
>>> Same questions for the second set (User Guide to Audio
>>> editing...)...
>>>
>>>
>>> Peter
>>>
>>>
>>> On 9/6/2012 11:29 PM, Gregg Vanderheiden wrote:
>>> here are two examples
>>>
>>> 1. Muse Test Suite, Part 1 Test Objectives (link
>>> <http://www.ist-muse.org/Deliverables/TF4/MUSE_DTF4.1p_V07.pdf>)
>>> & Part 2 Test Methods (link
>>> <http://www.ist-muse.org/Deliverables/TF4/MUSE_DTF4.2p_V05.pdf>).
>>>
>>>
>>> * Published together on Jan 6, 2006. Labeled as a set
>>> in 1.1 Scope.
>>>
>>> 2. User Guide to Audio editing with Audacity, Part 1 (link
>>> <http://www.jtoolkit.com/audio/Audacity_Guide.pdf>) &
>>> Part 2 (link
>>> <http://www.jtoolkit.com/audio/EditingAudioPart2.pdf>).
>>>
>>> * Published together in 2009 and labeled as a set in
>>> Part 2.
>>>
>>> /Gregg/
>>>
>>> --
>>> <oracle_sig_logo.gif> <http://www.oracle.com/>
>>> Peter Korn | Accessibility Principal
>>> Phone:+1 650 506 9522 <tel:+1%20650%20506%209522>
>>> OracleCorporate Architecture Group
>>> 500 Oracle Parkway | Redwood City, CA 94065
>>> ------------------------------------------------------------------------
>>> Note: @sun.com <http://sun.com/>e-mail addresses no longer
>>> function; be sure to use:peter.korn@oracle.com
>>> <mailto:peter.korn@oracle.com>to reach me
>>> ------------------------------------------------------------------------
>>> <green-for-email-sig_0.gif>
>>> <http://www.oracle.com/commitment>Oracle is committed to
>>> developing practices and products that help protect the
>>> environment
>>>
>>> --
>>> <oracle_sig_logo.gif> <http://www.oracle.com/>
>>> Peter Korn | Accessibility Principal
>>> Phone:+1 650 5069522 <tel:+1%20650%205069522>
>>> 500 Oracle Parkway | Redwood City, CA 94065
>>>
>>> <green-for-email-sig_0.gif>
>>> <http://www.oracle.com/commitment>Oracle is committed to
>>> developing practices and products that help protect the environment
>>>
>>>
>>> --
>>> ---------------------------------------------------------------
>>> Loďc Martínez-Normand
>>> DLSIIS. Facultad de Informática
>>> Universidad Politécnica de Madrid
>>> Campus de Montegancedo
>>> 28660 Boadilla del Monte
>>> Madrid
>>> ---------------------------------------------------------------
>>> e-mail: loic@fi.upm.es <mailto:loic@fi.upm.es>
>>> tfno: +34 91 336 74 11
>>> ---------------------------------------------------------------
>>> --
>>> <image001.gif> <http://www.oracle.com>
>>> Peter Korn | Accessibility Principal
>>> Phone:+1 650 5069522 <tel:+1%20650%205069522>
>>> 500 Oracle Parkway | Redwood City, CA 94065
>>> <image002.gif> <http://www.oracle.com/commitment>Oracle is
>>> committed to developing practices and products that help protect
>>> the environment
>>>
>>> --
>>> <image001.gif> <http://www.oracle.com>
>>> Peter Korn | Accessibility Principal
>>> Phone:+1 650 506 9522 <tel:+1%20650%20506%209522>
>>> OracleCorporate Architecture Group
>>> 500 Oracle Parkway | Redwood City, CA 94065
>>> ------------------------------------------------------------------------
>>> Note: @sun.com <http://sun.com> e-mail addresses no longer function;
>>> be sure to use:peter.korn@oracle.com
>>> <mailto:peter.korn@oracle.com>to reach me
>>> ------------------------------------------------------------------------
>>> <image002.gif> <http://www.oracle.com/commitment>Oracle is committed
>>> to developing practices and products that help protect the environment
>>
>
> --
> Oracle <http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 506 9522 <tel:+1%20650%20506%209522>
> Oracle Corporate Architecture Group
> 500 Oracle Parkway | Redwood City, CA 94065
> ------------------------------------------------------------------------
> Note: @sun.com e-mail addresses no longer function; be sure to use:
> peter.korn@oracle.com to reach me
> ------------------------------------------------------------------------
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
--
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 506 9522 <tel:+1%20650%20506%209522>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood City, CA 94065
------------------------------------------------------------------------
Note: @sun.com e-mail addresses no longer function; be sure to use:
peter.korn@oracle.com to reach me
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
Received on Tuesday, 11 September 2012 22:24:41 UTC