lynx

I've been looking at the UAAG last call for lynx (2.8.3 but my
comments apply to lynx in general as a tty browser).

Lynx only supports the Text "Content type label" (or let's say the
claim I want to make is only for Text).

It sounds, when reading 3.1, that I should be only looking at
checkpoint: 3.3, 4.1, and 4.2 ?

Later on in 3.3, it appears as if it's not the case.

So please clarify in 3.1.


In 3.3, it would good to have the list of "core" checkpoint listed
explicitly, in fact, maybe they should be listed in 3.1 under
"Generic" or "Core", to make clear that they are relevant when reading 
3.1 labels.

In 3.3, reading the "Unless" rule feels like a hack and makes me think
that maybe there is matter for unification of the "Content type" model
and these exception rules. Maybe it's just a bad/hack feeling and it's 
not possible in the timeframe you have.

Same for the Keyboard rule "exception" in 3.3.



In 3.5, why does the claim need to list the "checkpoints of the chosen
conformance level considered not applicable". Is there any ambiguity
when they don't ? (I guess yes and that's related to the lack of a
unified model for Content-type).


In 3.7 Conformance icons, the "must link" part should be qualified for 
Web content only, not for product packaging for instance (on paper).


Now onto the checklist (P1 only)

   * Checkpoint 2.1 Make all content available through the user interface.

So the process here is to first determine if this checkpoint is
"content type label" specific, right ?

So again, a list of all the core ones, or some annotation along the
checkpoint text (like next to the priority level) of the content type
or the coreness would be useful.

Since I only want to claim availability of text content for lynx, I
guess this one is satisfied.

Is that right ?

   * Checkpoint 2.2 For a presentation that requires user input within a
     specified time interval, allow the user to configure the user agent to
     pause the presentation automatically and await user input before
     proceeding. 

Yes, lynx doesn't change it's content without user action.

Well, in fact, I don't think it allows one to configure it, it just
doesn't do it.

   * Checkpoint 2.3 Provide easy access to each equivalent and each
     equivalency target through at least one of the following mechanisms:
     (1) allowing configuration to render the equivalent instead of the
     equivalency target; (2) allowing configuration to render the equivalent
     in addition to the equivalency target; (3) allowing the user to select
     the equivalency target and then inspect its equivalents; (4) providing
     a direct link to the equivalent in content, just before or after the
     equivalency target in document order. 

Lynx, as it only supports text, doesn't really have this issue.

   * Checkpoint 2.4 Allow the user to specify that text transcripts,
     collated text transcripts, captions, and auditory descriptions be
     rendered at the same time as the associated audio and visual tracks.
     Respect author-specified synchronization cues during rendering.

Not applicable (no multimedia supported).

   * Checkpoint 3.1 Allow the user to configure the user agent not to render
     background images. In this configuration, provide an option to alert
     the user when a background image is available but has not been
     rendered. 

Another one of the kind: doesn't render them anyway (just text, no
image support). N/A ?

   * Checkpoint 3.2 Allow the user to configure the user agent not to render
     audio, video, or animated images except on explicit request from the
     user. In this configuration, provide an option to render a substitute
     placeholder in context for each unrendered source of audio, video, or
     animated image. When placeholders are rendered, allow the user to
     activate each placeholder individually and replace it with the original
     author-supplied content. (Techniques for 3.2)

same

   * Checkpoint 3.3 Allow the user to configure the user agent to render
     animated or blinking text as motionless text. (Techniques for 3.3)

not supported.

   * Checkpoint 3.4 Allow the user to configure the user agent to render
     blinking images as motionless images. (Techniques for 3.4)

OK, I'll pass on the unsupported stuff from now on (image/audio/video).

  * Checkpoint 4.1 Allow the user to configure and control the reference
     size of rendered text with an option to override author-specified and
     user agent default sizes of rendered text. Make available the range of
     system font sizes. (Techniques for 4.1)

In lynx, the font size/color etc, is controlled by the host terminal
(say xterm in unix). So it that unsupported or satisfied ?

   * Checkpoint 4.2 Allow the user to configure the font family of all text,
     with an option to override author-specified, and user agent default,
     font families. Allow the user to select from among the range of system
     font families. (Techniques for 4.2)
   * Checkpoint 4.3 Allow the user to configure the foreground color of all
     text, with an option to override author-specified, and user agent
     default, foreground colors. Allow the user to select from among the
     range of system colors. (Techniques for 4.3)
   * Checkpoint 4.4 Allow the user to configure the background color of all
     text, with an option to override author-specified and user agent
     default background colors. Allow the user to select from among the
     range of system colors. (Techniques for 4.4)

same as above

   * Checkpoint 6.1 Implement the accessibility features of all implemented
     specifications (markup languages, style sheet languages, metadata
     languages, graphics formats, etc.). The accessibility features of a
     specification are those identified as such and those that satisfy all
     of the requirements of the "Web Content Accessibility Guidelines 1.0"
     [WCAG10]. 

ouch!
Lynx doesn't support half of the HTML4 stuff for table/longdesc/etc.

   * Checkpoint 8.1 Make available to the user the author-specified purpose
     of each table and the author-specified relationships among the table
     cells and headers. (Techniques for 8.1)

nada


   * Checkpoint 1.4 Ensure that the user can interact with all active
     elements in a device-independent manner. 

If keyboard access is considered as the bottom line device-independent
way in, sure.

BTW this checkpoint makes little sense to me as a particular UA may
be relevant to only one device channel, so asking it to support others
is weird.

   * Checkpoint 1.5 Ensure that every message (e.g., prompt, alert,
     notification, etc.) that is a non-text element and is part of the user
     agent user interface has a text equivalent. (Techniques for 1.5)

ok

   * Checkpoint 4.15 For user agents that support style sheets, allow the
     user to select from (and apply) available author and user style sheets
     or to ignore them. (Techniques for 4.15)

ok for lynx but a note: why the "if CSS" form here and not the "if
media", "if java" elsewhere ?

   * Checkpoint 4.16 Allow the user to configure how the selection is
     highlighted (e.g., foreground and background color, voice pitch, etc.).
     For graphical viewports, offer at least three rendering options,
     including colors and fonts. Allow the user to select from among the
     range of system colors and fonts. (Techniques for 4.16)

done by the terminal for lynx 

   * Checkpoint 4.17 Allow the user to configure how the content focus is
     highlighted (e.g., foreground and background color, voice pitch, etc.).
     For graphical viewports, offer at least three rendering options,
     including colors and fonts. For graphical viewports, allow the user to
     select from among the range of system colors and fonts. The default
     focus highlight mechanism must be different from the default selection
     highlight mechanism. 

Done by the terminal, but the part on the focus/selection being
different kind of annoy me. It's the same and I'm not sure it's lynx
problem or xterm problem...


   * Checkpoint 7.1 Allow the user to navigate among all viewports
     (including frames). (Techniques for 7.1)

ok

   * Checkpoint 7.2 Associate a point of regard with each state in a
     viewport's browsing history and when the user returns to a state in the
     history, restore the associated point of regard. 

ok

   * Checkpoint 7.3 Allow the user to navigate all active elements. If the
     author has not specified a navigation order, allow at least forward
     sequential navigation of elements, in document order. (Techniques for
     7.3)

yes

   * Checkpoint 8.6 Implement selection, content focus, and user interface
     focus mechanisms. Implement them according to system conventions (per
     checkpoint 5.8). (Techniques for 8.6)

ok

   * Checkpoint 8.7 Provide a mechanism for highlighting the current
     viewport, selection, and content focus. (Techniques for 8.7)
   * Checkpoint 9.1 Provide information to the user about current user
     preferences for input configurations (e.g., keyboard or voice
     bindings). (Techniques for 9.1)
   * Checkpoint 9.2 Avoid default input configurations that interfere with
     operating system accessibility conventions. (Techniques for 9.2)

ok

   * Checkpoint 1.1 Ensure that every functionality available through the
     user interface is also available through every input API that is
     implemented by the user agent. This checkpoint does not require
     developers to reimplement the input methods associated with the
     keyboard, pointing device, voice, and other input APIs. (Techniques for
     1.1)

I don't think there's any input API other than the terminal keyboard,
so OK ?

   * Checkpoint 1.2 Use the standard input and output APIs of the operating
     system. Do not bypass the standard output APIs when rendering
     information. (Techniques for 1.2)

scanf() is standard API in C.

   * Checkpoint 1.3 Implement the operating system's standard API for the
     keyboard and ensure that every functionality available through the user
     interface is available through this API. (Techniques for 1.3)

?

   * Checkpoint 5.1 Provide programmatic read access to HTML and XML content
     by conforming to the W3C Document Object Model (DOM) Level 2 Core and
     HTML Specifications and exporting the interfaces they define.
     (Techniques for 5.1)

ouch

   * Checkpoint 5.2 If the user can modify HTML and XML content through the
     user interface, provide the same functionality programmatically by
     conforming to the W3C Document Object Model (DOM) Level 2 Core and HTML
     Specifications and exporting the interfaces they define. (Techniques
     for 5.2)

no DOM

Why is there a "if CSS supported" and not a "if DOM supported" ?

   * Checkpoint 5.3 For markup languages other than HTML and XML, provide
     programmatic access to content using standard APIs (e.g.,
     platform-independent APIs and standard APIs for the operating system).
     (Techniques for 5.3)

na


For Accessible Documentation (Priority 1)

   * Checkpoint 10.1 Ensure that at least one version of the product
     documentation conforms to at least Level Double-A of the Web Content
     Accessibility Guidelines 1.0 [WCAG10]. (Techniques for 10.1)

I quickly checked the online lynx doc at lynx.browser.org and it looks 
fine (AA that is)

   * Checkpoint 10.2 Document all user agent features that promote
     accessibility. (Techniques for 10.2)

It's there somewhere I'm sure (that one of the main the purpose of
this browser). 

   * Checkpoint 10.3 Document the default input configuration (e.g., default
     keyboard bindings). (Techniques for 10.3)

ok



OK, so lynx do not get even A, because of lack of support for HTML4
stuff and lack of DOM support.

Received on Wednesday, 8 November 2000 11:15:58 UTC