Re: Test run of User Agent (Opera 5.1/Win)

Ian Jacobs (ij@w3.org) wrote:
> Jonny Axelsson (jax@opera.no) wrote:	

>> 1.1 Question: what is "fully operate" [1][conformant?]	
>> It is described in further detail below. The question remains,	
>> should all commands be available in all modalities? Also if it is	
>> not a "core function"? Opera has a great number of assistive	
>> functions, the vast majority of which are multimodal. Question:	
>> if a fully comformant UA adds a new function that is nonmodal, is	
>> it as comformant as before, less conformant or non-conformant? 

> Please let me know if I have understood correctly: are you	
> asking, for example, whether "fully operate" includes "operation	
> of the menus" or just "operation of the (core) functionalities	
> that are made available through the menus"? 

This was a paraphrase from the techniques document [1], "Ensure that 
the user can operate the user agent fully through keyboard input alone." 
What I wanted to know was if every function however peripheral must 
have keyboard access. That would be a rule easy to check, but the risk 
is that by adding some minor function without keyboard access, the browser 
suddenly becomes non-conformant.
[1] <http://www.w3.org/TR/2001/WD-UAAG10-TECHS-20010409/#gl-device-independence>

> Our language for making the distinction became too complicated and 
> confusing, so we gave it up in favor of the "fully operable" formulation. In 
> general, we take the following approach: "As long as the UA provides 
> service "X" one accessible manner, it can provide that service in any 
> number of inaccessible ways as well." 

> In the case of 1.1, we could probably say something like this in a Note:  
> "The user agent is not required to make all user interface controls 
> keyboard operable. To satisfy this checkpoint, each functionality offered 
> by the user agent must be available through at least one keyboard 
> operable mechanism." Please let me know if this is consistent with 
> what you were thinking. 

There might be some disagreement on the enumeration of "each functionality" 
in the specific conformance claims, but if judged with reason this should do.



>>2.2 Text source [1][conformant]	
>>We do show source view. It is unclear what other XML/HTML views
>>apart from source view is referred to. The most natural way to do	
>>so would be through CSS. 

>I'm not sure what you mean by "what other views are referred to". 
>This checkpoint only refers to a (single) text source view. 

This was mostly taken from Techniques. On second reading it seems that 
"source view" is really intended as text view with everything non-text removed, 
and not what I associate with "source view" (what the browser gets from the 
server or file system). In the case of Opera, you may get better results doing 
that (turning off graphics, tables, multimedia, frames, scripts, possibly CSS). 
Incidentally what Techniques suggest is what we do with our mail and news 
client (adding markup and style to a text file--the mail/news message). As a 
side note to that, guessing URLs in a text file is always that, guessing. While 
we usually get this right there must be URLs we will believe is a normal text 
string and vice versa.



>> 2.4 Infinite timed input [1][conformant]	
>> We don't have any timed controls yet, but we may have and this	
>> will be on our mind. Question: would one hour be a close enough	
>> approximation of "infinite"? 

> I don't think so. It seems pretty reasonable that an hour would suffice, 
> but that doesn't mean infinite. We could try to	say "at least an hour", 
> but why not 30 minutes? We chose not to have to draw the line, so we 
> said infinite. Is there a technical reason why you would choose an hour? 

Just a minor UI one. This means that if there is a timed control, like our 
user configured page refresh rate for instance, there must almost always
be a separate check box (sometimes setting the interval to 0 would have
the same effect).



3.1 Configure no background image [1][conformant?]	
>> *{background-image: none !important}, also a separate option. I
>> am confused by "option to alert the user". 

> I think that the reasoning is as follows: It's a P1 requirement to not load 
> background images automatically, which is more than a requirement 
> just to be able to turn them off. If the requirement were just to be able  
> to turn them off, then the user could have them on all the time and turn 
> them off when necessary. In this case, the alert requirement could be a 
> P3 requirement. However, since the P1 requirement established by 
> the WG is to not render them automatically (on load, for instance), this 
> means that the user is likely to have this configuration on all the time. 
> In which case, the alert requirement is just as important.	It lets the user 
> know that there's a background image (that might be important) and the 
> user can choose to manually reload. 

I am at loss how to implement such an alert in a CSS context. Any element 
can have a background image, there can be any number of CSS 
statements applicable to any element and every such statement can be 
overridden in the cascade (UA < User < Author < Author!important 
< User!important). DOM2Styles adds further complications to this by 
adding another level to the cascade as well as the ability to dynamically
change where and what and when such a background image is added.



>> 6.1. - 6.10 User Agent and DOM [div][non-conformant]	
>> I have serious issues with this section. As I read it, it would be an  
>> absolute requirement to fully implement the DOM to get even an A level 
>> conformance. No other W3C spec makes DOM a requirement. 

> Actually, there are other specs that require support for the DOM.  
> For instance the SVG specification says the following in appendix B.1 [1]: 
> <BLOCKQUOTE> The SVG DOM is builds upon and is compatible with the 
> Document Object Model (DOM) Level 2 Specification [DOM2]. In particular: 
> The SVG DOM requires complete support for the DOM2 core [DOM2-CORE]
> </BLOCKQUOTE>	  
>  [1] http://www.w3.org/TR/SVG/svgdom.html#SVGDOMOverview 

> It makes sense for W3C specifications to build upon one another. UAAG 1.0 
> requires conformance to other W3C specs (or other specs that support 
> WCAG 1.0) at a P2 level in checkpoint 8.2 

Yes, I would expect other DOMs reusing existing DOM modules as far as 
possible, and there are other direct linkages, XSLT being directly dependent 
on XPath for instance. This is not something to be done lightly however. 
Notably SVG itself does *not* depend on DOM and comes in four variants 
(with/without DOM, with/without animation). Another example is XHTML. It 
does not require CSS even though that could have been natural, nor on 
DOM nor on anything else but Unicode and XML.

I have read 8.2 as "whatever you implement, implement it right", and not as 
"implement every W3C spec in your field of interest". I strongly agree with 
the former, but not with the latter. To take an IETF example, it would be OK, 
if not necessarily wise, to have a browser that supports FTP, but not HTTP. 
But if it implements HTTP, it should implement HTTP well enough not to 
cause problems for HTTP servers and proxies and ultimately the user.


>> Opera is about to implement DOM (W3C of course), 
>> other browsers may not. My suggestion is that this is made into a	
>> separate "mode" so that one UA can have excellent accessibility
>> but no API and another can have no accessibility but can get one	
>> through its extensive API. 

> We considered different conformance models, one of which allowed for
> "stand alone" conformance (refer to issue 89 [2]).	At our 6 October 1999
> teleconference [3], we rejected the split because it undermined 
> interoperability with assistive	technologies. 
> [2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#89 
> [3] http://www.w3.org/WAI/UA/1999/10/wai-ua-telecon-19991006 

It would still be obvious whether or not the UA will be appropriate 
for a given task. If you have two browsers, one with excellent accessibility,
but no DOM, and another with no accessibility, but full DOM support, you
would choose the former unless you have (say) a good screen reader 
based on DOM, in which case you may opt for the latter. DOM would be 
no different from other opt-outs (e.g. Opera having no native support for 
either speech or voice, but is still quite accessible for other uses).

Disqualifying a UA for not having DOM support is a bit the same as 
disqualifying a graphical UA for not supporting SVG,  because arguably 
SVG is a much more accessible format than GIF or JPEG. It is possible to 
salvage more information from a SVG graphic if it is sanely made, and it 
is possible to make assistive technologies that will take advantage of that.

By having DOM (or SVG or any other huge W3C specification) as a 
pre-requisite you will turn away a number of user agents, in particular the 
small or specialized ones. They will never bother to make a conformance 
claim because they will be excluded from the start.

> Our target conforming user agents are user agents running on PC-type 
> environments (refer to the discussion of section 1.2 "Target user agents" 
> in the 9 April draft). We are not as concerned with user agents running 
> on very small mobile devices (although we do not exclude conformance 
> by them in principle). Future guidelines may be more tailored to memory 
> and other constraints on mobile devices, etc. 

This is written on a biggish small device,  a Psion (we are not to blame for 
the email program) and yes, there may be some Win/Mac/Linux accessibility 
features that will not be available on our Opera version for Psion and similar 
devices. We will hopefully find appropriate equivalent features for mobile 
devices, and we would be interested in a MUAAG profile or whatever 
it will be called.



>> 10.4 Outline view and label for content [2][conformant?]	
>> A complex checkpoint that maybe should be split up. 
> I will see what I can do to clarify the checkpoint. Can you explain 
> specifically what was complex?
 
Complex as in trying to do several partially related things at once, not 
complex as in hard to understand. My thoughts were that maybe it's better
to separate outline from label, but then I may have read too much into
"outline" (to which my comment on H1-H6 still stands). For a CSS2
compliant UA, it is quite simple, 

h1:before, h2:before,...h6:before {content: "Headline: ";}.
/* and so on */

For other UAs this requirement can be costly, as you most likely
would have to special case each structural element.


Jonny Axelsson,
Opera Software

Received on Thursday, 10 May 2001 08:44:31 UTC