Your comments on WCAG 2.0 Last Call Draft of April 2006 (6 of 6)

Comment 1:

Source: http://www.w3.org/mid/20060621153133.3B5E3BDA8@w3c4.w3.org
(Issue ID: LC-865)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0130.html

Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):

text equivalents for struggling students and people with LD are often
of a very different natures to the SC described.
They would typically not have all included text, point out the key
detail that someone is needs to understand
Alt tags are often verbose, such as explaining or giving a sentence of
context to a diagram. We often have multiple prodnotes (using HTMl
with  Daisy XML as a base) for a single picture often linked to
different regions

descriptive alt tags would be omitted – the would just confuse the
user who we are trying to help identify key content and concepts.

Would such a page be conformant?

note there are many more people with these needs then who are blind.
And blind users are getting all the key information anyway.
 Also note:
Alt tags and prodnotes are a great way to put info in a page for LD
without changing the genral use

Proposed Change:

creat an alternive SC set for pages for people with LD.

----------------------------
Response from Working Group:
----------------------------

WCAG is a set of guidelines for general use pages. WCAG 2.0 has been
written assuming that authors can produce a single version of the
content that could be made accessible to everyone, although assistive
technology may be needed to transform the content into an appropriate
rendering. Because of the danger of excluding people with multiple
disabilities, the working group has been reluctant to require multiple
versions of content targeted to different audiences. We are also
concerned about the privacy issues involved in requiring people to
self declare disabilities in order to get suitably tailored output.
The guidelines permit alternate versions of Web pages, but do not
require them.

We agree that there should be an activity that focuses on how to
create pages just for people with learning disabilities. That is
beyond the scope of WCAG itself. But we hope that related activities
can develop techniques for content designed specifically for people
with different cognitive, learning, and language disabilities. This
would be important to determining whether we can achieve a single
version of content that is accessible to all, or whether multiple
versions of content would be needed.

----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/20060621153218.D8A02BDA8@w3c4.w3.org
(Issue ID: LC-866)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0131.html

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

Are we OK with the support robust technology section?

To me , if I were reading a guideline to support robust technology I
would expect: Support more then one operating system. Or support at
least on free operating system, and free useragents were possible.
Use technologies that support more then one independent assistive
technology . That type of thing...

When they say something can be parsed - they do not say by who - is it
some proprietary format that only works on one  environment?



Proposed Change:

----------------------------
Response from Working Group:
----------------------------

To make this requirement easier to understand, we have reworded SC
4.1.1 to clarify that it must be possible to parse content without the
need for user agent repair. The revised SC reads as follows:

4.1.1 Content implemented using markup languages has elements with
complete start and end tags, except as allowed by their
specifications, and are nested according to their specifications.
(Level A)

Note: Start and end tags that are missing a critical character in
their formation, such as a closing angle bracket or a mismatched
attribute value quote are not complete.

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/20060621153544.463AFBDAA@w3c4.w3.org
(Issue ID: LC-868)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0132.html

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):


The success criteria a are not stable in the future, and do not
capture everything that you need to do. They are the testable  aspects
of current conformance
I think this limitation needs to be emphersized. Specicly
Success criteria by themselves do not necciraly mean that the piont of
the giudline was acheived

-


Proposed Change:

Why not putting rules of thumb in the guidelines themselves? Success
criteria are only measurable aspects of a rule of thumb.
People should not turn success criteria into a checklist whilst ignoring that.

----------------------------
Response from Working Group:
----------------------------

The success criteria need to be testable or else people cannot tell
when they have conformed to the success criteria and thus WCAG 2.0.
The document states that more can be done than the SC and provides
advisory techniques to that end. We have added more advisory
techniques to cover recommendations for which we have not been able to
develop testable success criteria. We have also clarified in the
introduction that even satisfying all success criteria will not meet
the needs of all people with all disabilities.


----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/20060621153616.E5400BDF7@w3c4.w3.org
(Issue ID: LC-870)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0133.html

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

The success criteria are not stable in the future, and do not capture
everything that you need to do. They are the testable  aspects of
current conformance
I think this limitation needs to be emphasized. Specificly
Success criteria by themselves do not neccesarily mean that the point
of the guidleine was achieved-



Proposed Change:



Change the name consistently or currently  testable criteria

----------------------------
Response from Working Group:
----------------------------

Since the success criteria are the set of testable statements that can
be used in determining conformance to WCAG 2.0, the working group felt
that the addition of "consistently" or "currently" would not be
helpful in clarifying this issue. However, we have modified the the
last paragraph of "The Four Principles of Accessibility" to clarify
that meeting the success criterion may not fully address the general
principles and guidelines that they relate to, and that additional
advisory techniques are provided to go further.

The Understanding WCAG 2.0 document also makes this clear and lists
the advisory techniques for guidelines and success criteria. This
gives the working group the option of making techniques available to
authors that make it possible to go above and beyond the conformance
requirements and more completely address the intent of the guidelines
and principles.

----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/20060621155301.66CBD47BA1@mojo.w3.org
(Issue ID: LC-871)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0136.html

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

These are the steps or tasks that have been identified to make script
based interfaces operable.  This is taken from
http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html and was well
researched. Without any one of these tasks many interfaces will not be
accessible.

My I suggest that we review WCAG to test if these steps are suffiently
included and WACG  does  require  each task as described hear. For
 for example
3.1.3 Information and relationships conveyed through presentation can
be programmatically determined, and notification of changes to these
is available to user agents, including assistive technologies.


Does that include all the group identification as necciasy

Anyway, hope this is useful


steps or tasks are as follows......
3.1 How To Build Applications Using Roles
This section is informative.

3.1.1 Step 1: Use your native mark up as well as you can
Use the semantic elements that are defined in the native markup
language. For example, if you are using [XHTML] it is better to use
the [XHTML] checkbox than to use a div element with role checkbox.
Because properly used [XHTML] content is already repurposible, roles
are best used when the mark up language does not support all the
semantics that you need. When a role is used the semantics and
behavior of the element are overridden by the role behavior.

3.1.2 Step 2: Find the right roles
Set roles to make sure elements behave predictably and that correctly
describes the behavior of each element within your application (unless
elements behaviors are fully described by the native markup language).
Roles for interactive elements should support all the states that the
element could use.

3.1.3 Step 3: Look for groups
Look for groups within a page, and mark them using the most
appropriate role that best describes their usage.

For example: a region of the page that is contains a group of elements
that are likely to change through an AJAX application could be tagged
as a \"liveregion\".

3.1.4 Step 4: Build relationships
Look for relationships between groups and mark the using the most
appropriate property or attribute.

Sometimes the relationships can be made clear via the native mark up
language, such as the label tag in [HTML].

Sometimes this can be implied via the DOM. For example, when a well
marked up list contains list items it is known that they belong to the
containing list. In such cases you do not need to set additional
properties to make that explicit.

In other cases use the states and adaptable properties module to state
relationships. For example: if a container A contains search results,
and container B contains the search controls, the mark each container
as a region and set the aaa:controledby property in region B to region
A.

3.1.5 Step 5: Set properties
Set properties until the behavior of the element is defined.
Control the behavior of the element using device independent events,
states, and properties.
Extra states and properties have been provided by the States and
Adaptable Properties Module. For example: If the user is required to
fill in a form element set the aaa:required property to true.

An important addition in the States and Adaptable Properties Module is
new extensions of TABINDEX. Now, with the TABINDEX change, the author
is allowed to give any element keyboard focus (and not just form
elements or anchors). In this paradigm shift, the user experience
should be to use tabbing or keyboard mnemonics to move focus to
widgets on the web page and then use the arrow keys to navigate the
object.

Example: building a tree view in XHTML 1.0
This section is informative.



A basic tree view allows the user to select different list items and
expand and collapse embedded lists. Arrow keys are used to navigate
through a tree, including left/right to collapse/expand sub trees.
Double clicking with mouse also toggles expansion.

Step one: Look at your native mark up language
There is no a tree element in [XHTML] 1.0 that supports our behavior
including expansion, so we will need to use roles. Therefore, our
first step is setting roles.

Step two: Finding the right roles
Our tree will need roles that support embedded list behavior and
expandable/collapsible embedded lists. The roles that support tree
behavior for a tree are:

Tree: the main container element for our treeA form of a Select (or,
generally, of a list having groups inside groups) - where sub trees
can be collapsed and expanded.

Treegroup: This is a group of sibling tee items that have a common
parent. Intended use is for creating groups of treeitems within a tree
container.

Treeitem: An option item of a tree. This is an element within a tree
which may be expanded or collapsed.

Step three and four: Look for groups and build relationships
Tree relationships can be made simply via the Dom and logical
structure of your page.

A tree element will be the main container containing all other
elements in the tree.

Each selectable item in the tree will be a treeitem

When a tree item contains a embedded list of tree items they will be
all embedded in a treegroup. A treegroup should be contained inside
the tree item that is the parent item.

Tree relationships are like list relationships in [XHTML]. A treegroup
and tree elements act like list containers (OL and UL). A tree item
acts like a list item (li) in [XHTML].

Because treeitems and treegroups are commonly both use div elements it
is recommended to ad a comment next to closing treeitems that contain
embedded tree groups

Veggies
Green
Asparagus
Kale
Leafy
Lettuce
Kale
Spinach
Chard
---close leafy
Green beans
---close green
Legumes
Yellow
Bell peppers
Squash
---close yellow
---close veggies
 ---close tree
Sometimes a tree structure is not explicit via the Dom and logical
structure of a page. In such cases the relationships must still be
made explicit using the properties module.

Example:

Yellow
..
Bell peppers
Squash
Although this is allowed it may affect performance Step 5: Use
properties Control the behavior of the element using Events and
states, For example, use the aaa name space with supporting scripts to
control what tree elements are expanded
Yellow
And use events to device independent events with supporting
javascripts to handle user interaction.
Then create javascript support to control the event driven behavior or
the application. Proposed Change:

----------------------------
Response from Working Group:
----------------------------

During the development of WCAG 2.0 the Working Group made certain that
the success criterion do not prevent the use of Dynamic Web Content
Accessibility techniques.  We believe that each of the steps you cite
are covered by one of the success criterion listed below:

1.3.1: Information and relationships conveyed through presentation can
be programmatically determined, and notification of changes to these
is available to user agents, including assistive technologies.

2.1.1: All functionality of the content is operable through a keyboard
interface without requiring specific timings for individual
keystrokes, except where the underlying function requires input that
depends on the path of the user's movement and not just the endpoints.

4.1.1: Content implemented using markup languages has elements with
complete start and end tags, except as allowed by their
specifications, and are nested according to their specifications.

4.1.2: For all user interface components, the name and role can be
programmatically determined, states, properties, and values that can
be set by the user can be programmatically determined and
programmatically set, and notification of changes to these items is
available to user agents, including assistive technologies.

The steps in your example map to one or more success criteria:
Step 1: Use your native mark up as well as you can is covered by SC
1.3.1, 4.1.1, and 4.1.2
Step 2: Find the right roles is covered by 4.1.2,
Step 3: Look for groups is covered by 1.3.1, 4.1.1, and 4.1.2.
Although these success criteria do not explicitly mention groups, they
do cover relationships. This satisfies the group requirement for
current technologies such as HTML which do not allow for the addition
of specific group roles but do convey the meaning of groups through
specific elements such as lists.  Dynamic Web Content Accessibility
techniques can be used to add roles to HTML when Dynamic Web Content
Accessibility technologies are included the baseline.
Step 4: Build relationships is covered by 1.3.1, 4.1.1, and 4.1.2.
Again, this may not be as explicit as you would like but is supported
by current technologies.
Step 5: Set properties is covered by 4.1.2.
Any requirements for keyboard support are covered by 2.1.1 and 2.1.2.

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/20060622064809.2A6B233201@kearny.w3.org
(Issue ID: LC-877)

http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0149.html

Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):

I think WCAG itself (agendas forms etc) need to be more usable for
people with Cognitive Imparments like impaired  short term  /visual /
auditory memory

If we can not make our own system usable then people with these
imapairments can nt comment and affect the guidlines

It also clearly shows a lack of understanding of how to make content
accessible for people with LD and Cognitive limitatsions


As a side note I have participated in a few W3C groups and I find WCAG
the hardest for people with LD to participate in.

If anyone thinks I am unable to undersatnd the concepts they should
refier to http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html

It is the presention that makes it inaccessible not the content


Proposed Change:

----------------------------
Response from Working Group:
----------------------------

We have attempted to make our processes and documents more accessible,
but recognize that they have a long way to go. We have limited tools
and resources and are open to specific suggestions for improvement.

Received on Thursday, 17 May 2007 23:41:00 UTC