17 results found.
Part of Item:
Comment Type: QU
Comment (Including rationale for any proposed change):
To what extent is this implicit in the definition of "programmatically determined" and all of the criteria requiring that aspects of the content must be able to be "programmatically determined"?
Does programmatic determination impose a stronger requirement than sc 4.1.1 in so far as it demands the use of representations supported by user agents? It is unclear how one could satisfy 1.3 if the user agents can't unambiguously parse the content in the first place.
Proposed Change:
There is often overlap but not necessarily always overlap. For example, two browsers might parse a document differently using repair techniques. A particular item might be programmatically determinable but be located in two different places on the page in the two renderings. It doesn’t affect the meaning, but the inability to parse the markup can break AT where it doesn’t break other browsers.
Item Number: Success Criterion 4.1.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
In guideline 4.1.1 does "parsed unambiguosly" mean "well formed" or "valid"? The techniques seem to suggest that markup must be valid, though you would be hard pressed to find invalid code that disrupts any relatively recent screen reader's ability to read a Web unit. It takes severely broken markup to affect accessibility, or specific types of errors (such as broken table structures). While I am all for valid markup, it is *not* a requirement for accessibility in most cases, particularly at level 1. I can see this requirement at level 2 perhaps.
Proposed Change:
What would be appropriate here to have a well formed requirement at level 1, and valid at level 2. And still this really has to do with compatibility with future technologies, rather than affects on accessibility using current technologies.
We have reworded SC 4.1.1 to require that content can be parsed without error.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The exclusion of validity is a huge step backwards for web accessibility. A valid document ensures consistent rendering, regardless of user agent.
Proposed Change:
That validity be added as a requirement for conformance to success criteria.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
4.1.1 Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.
I find this checkpoint very hard to comprehend. It seems that it should be handled by a success criterion that requires conforming to spec. But I looked at some of the background discussion. I am not sure now how to improve.
Proposed Change:
To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:
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.
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.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The definition of "parsed unambiguously" is rather ambiguous, and the gudelines themselves don't explain what is required. Does this mean a particular UA must have the same structure on each parsing of the same page (which only requires that UA behave deterministically) or that *all* UAs get the same structure (which is impossible without having all UAs store their data in the same way)?
For accessibility, it is vital that data be presented in a manner that complies with a published standard - otherwise how do UA-makers, or people who want/need to write their own parsing tools know what to expect and how to handle the data. With a multiplicity of UAs, the only sensible interpretation of "parsed unambiguously" is that the data stream complies with a published standard. That being the case, the guidelines should state this.
Proposed Change:
Simplify and strengthen the guidelines by removing the concept of "parsed unambiguously", and replace it with a guideline that says that data formats used must comply with a published specification (to be referenced in the baseline).
(Of course this may be an author-published one - though authors should be discouraged from doing so.)
To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:
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.
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.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
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:
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.
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
It\'s still unclear what \"parsed unambiguously\" means when applied to CSS documents. Even a loose interpretation is still a heavy burden for authors as this SC is level 1 and may not improve accessibility.
(This was discussed on list but no resolution.)
Proposed Change:
Clearly define what \"parsed unambiguously\" means when applied to CSS documents. Move SC to level 2 for CSS documents.
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.
We believe this is appropriate at Level A for CSS as well as other technologies.
it is not that the content can be parsed unambiguosly or not. That is a property of the language, not of the processor of the language. If the language is ambiguous then a parser could take arbitrary decisions in interpreting the sentences. Like Italian. HTML, not even 2.0, was never ambiguous. And if user agents were strict since the beginning, web authors would have never been allowed to write incorrect html.
Proposed Change:
what 411 should say is that authors should write syntactically correct code, which is what the techniques say.
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.
4.1.1: How is this to be tested?
Proposed Change:
Provide information
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.
Information about how to test this criterion is available in Understanding 4.1.1.
4.1.1 requires that Web content to be parsed unambiguously. Does this require the formal specifications be open, so that new user agents can parse the content? For example, suppose the baseline specifies just one Web browser, that implements rules for applying defaults to resolve any potential ambiguities in HTML that might be interpreted differently if another browser were used; is the HTML parsable unambiguously within the scope of the baseline? As another example, suppose a Web uses a proprietary data format that only a single plug-in can render; does it matter if it's parsable unambiguously if there is only one renderer?
Proposed Change:
Insert the phrase ", using publicly available specifications", to read "Web units or authored components can be parsed unambiguously, using publicly available specifications, and the relationships in the resulting data structure are also unambiguous.
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.
When a Web unit is not valid, or not conforming to a specification, how can one be sure if the Web unit is able to be parsed unambiguously?
To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:
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.
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.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Comment: The term, "parsed unambiguously," or "parsed into only one data structure" is not good enough to comply with the principle 4. The principle states that "content should be robust enough to work with current and future user agents." Then, if web units or authored components are well-formed but include information not based on chosen technologies, can we guarantee that this information is conveyed? Therefore, I believe if forward compatibility is important, "conforming to specifications" would be better than "parsed unambiguously."
Proposed Change:
Using the phrase "conforming to specifications" instead of the phrase "parsed unambiguously."
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
I know this has been brought up before. I am in agreement that validity needs to be a requirement at level 2.
Proposed Change:
Put \"Create documents that validate to published formal grammars\" in as a level 2 requirement.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Technical/substantive issue?
The current requirement fo unambiguous parsing is impossible to meet -
there are always multiple ways of parsing any data.
Instead I suggest the old wording of "conforms to formal published
grammars".
This makes it feasible for User Agents to recognise the content and parse
it either according to the rules for such grammars, or in cases where it
is necessary (such as HTML) to use specifically adapted parsing techniques.
cheers
Chaals
To make this requirement easier to understand, we have reworded SC 4.1.1 as follows:
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.
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.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Comment: WCAG 2.0 doesn't require validity. Can authors use UA-specific elements such as marquee, blink and so on? It is less certain on this issue through the documents.
Not all deprecated elements and attributes present a problem for assistive technologies. The blink element is covered by F47: Failure of SC 2.2.2 due to using the blink element. For marquee, authors would need to meet the requirements defined in SC 2.2.3.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Comment: Validity check is important process to increase accessibility. "Guidelines for Different Components" (http://www.w3.org/WAI/intro/components.php#guidelines) says "WAI guidelines are based on the fundamental technical specifications of the Web, and are developed in coordination with:" If WCAG does not mention to validity, readers of WCAG think WCAG WG thinks little of Web standards.
Proposed Change:
We propose to add Level 2 Success Criteria that requires validity.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Affiliation: None
Document: W2
Item Number: ensure-compat-parses
Part of Item:
Comment Type: technical
Comment (Including rationale for any proposed change):
Just a note that you asked for comments and from my own personal trawl of the archives, I found 19 separate comments related to validity/unambigous parsing. Of these, 18 of the comments desired returning to the \'validates\' criteria as used in WCAG 1 at either Level 1 or 2. That\'s almost 95% of the people making a comment wanting validity back.
(also see public posting on same:
http://www.thepickards.co.uk/index.php/200606/validity-those-taking-up-arms/
)
Proposed Change:
Re-include validity at level 2 as a strenghtening of SC 4.1.1.
The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.
The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1.
Developed and maintained by Jon Hardin at the Trace Center, University of Wisconsin-Madison.
$Date: 2007/05/30 15:32:52 $ $Author: bcaldwel $