Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Possible Violations ?

Options
LegacyForum
LegacyForum Posts: 1,664 ✭✭
Hi,
I noticed that most of the errors that Webking generates of the severity type "Possible Violations" or "Possible Severe Violations" are just warnings. Further, they all seem to be warnings of JSP or HTML errors(like a missing header in a table for example), rather than accessibility errors. Any clarification on this would be really appreciated.

Thanks

Comments

  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    edited July 2004
    Options
    In general we use the following guidelines to define the severity of a rule. Issues marked with "Possible" may often be warnings because, for some reason, the rule cannot be absolutely certain that a violation has occurred (either because the issue is not precisely defined, or the issue can be handled different ways, only one of which the rule covers, etc.).


    Informational:
    [*]Issues involving style as opposed to correctness OR
    [*]Issues involving opinion as opposed to correctness (e. g., some people do it this way and it is valid--some people do not and it is valid) OR
    [*]Any other issues that are not matters of correctness.

    Possible Violation:
    [*]Any issues involving correctness but are not critical for proper functionality, appearance, conformance, etc. (this makes it a "Violation").
    [*]It is "Possible" for:
    ----Issues involving correctness as defined above, but do not have an algorithmic definition and thus cannot be checked with high precision OR
    ----Issues involving multiple correct solutions, of which this rule only checks for one/some.
    [*]Issues are regarded as "critical" based on the impact of their correctness on the end result. For example, an issue is critical if an object cannot or is unlikely to function, conform, etc., when the issue is handled incorrectly.

    Violation:
    [*]Any issues involving correctness but are not critical for proper functionality, appearance, conformance, etc., and are not considered "Possible" as defined above.

    Possible Severe Violation:
    [*]Any issues involving correctness that are also critical for proper functionality, appearance, conformance, etc. (this makes it a "Severe Violation")
    [*]It is "Possible" as defined under "Possible Violation."

    Severe Violation:
    [*]Any issues involving correctness that are also critical for proper functionality, appearance, conformance, etc., and are not considered "Possible" as defined under "Possible Violation."
  • LegacyForum
    LegacyForum Posts: 1,664 ✭✭
    Options

    Further, they all seem to be warnings of JSP or HTML errors(like a missing header in a table for example), rather than accessibility errors.

    If a table is missing headers and is a data table, this is an accessibility error (see WAI Checkpoint 5.1 and 5.2). Header information is used by screen readers to indicate what information a data cell refers to. The value "42" is meaningless on its own, but given the header information "degrees Celsius" or "miles per hour," the number has a context. When a user cannot see the table, it is much more difficult to align a cell with its possible header. When you programmatically link a cell to its header, you give the screen reader the ability to read "degrees Celsius: 42."

    That being said, the rule that checks for missing headers and other table accessibility violations (TableAccessibility.rule) uses a heuristic in deciding if a table is being used for layout or data purposes. (For more information on this heuristic, please see the TableAccessibility documentation available through the WebKing Manual, p. 502). It is not possible to be algorithmically certain if a table is being used for layout or data purposes. Because it is using a heuristic to make this distinction, all errors reported through it are marked as "Possible."

    If you are having trouble with a layout table that looks like a data table, one work-around built into the rule is to add
    CODE
    summary="layout"
    in the table tag for that layout table. The TableAccessibility rule will then treat the table as a layout table, no longer requiring that cells have properly defined header information.