Action: Write ACTF rules in JSON was RE: YSlow rules for analyzing performance question
Michael A Squillace
All:
A community is forming around the so-called "Firebug Accessibility Dashboard" work and some of those involved were on a call the other day in which I took an action item to write our Eclipse Accessibility Tools Framework (ACTF) rules (now expressed as a combination of XML and JavaScript) in JSON. I am CCing the free aria group since that is where we decided to host the FAD discussions for now and responding to this particular note since the YSlow approach is similar to what I have put together.
Briefly, ACTF works from within Eclipse and "attaches" itself directly to the SWT Mozilla browser widget. Currently, a validation is triggered either when a document is loaded or when a DOMNodeInserted or DOMAttrModified event takes place. (We plan to expand validation-triggers and make these user-configurable in future releases.) The rules against which validations take place are written in XML and JavaScript. I have attached relevant files for web accessibility validation based on the IBM Web Accessibility Checklist v3.5 (which is based on WCAG 1.0):
http://www.ibm.com/able/guidelines/web/accessweb.html
I have included only relevant parts of the XML markup for the rules that I have encoded in JSON. The first rule is the standard check for alt tags on images (but is somewhat flawed since it does not allow alt=""). The second set of rules is for INPUT elements. The first checks to see that an alt tag is present for type="image" INPUT elements and the second checks to see that, for each INPUT element, a LABEL element is present with a for attribute pointing to the id of that INPUT element. Notice that the nodes that are examined must have tag names ("nodeNames" in ACTF parlance) that match the top-level tag names in the XML markup. We are working on ways to express other types of "criteria" such as attribute value matches or criteria that check the textual content of elements. The point is that the nodes to be selected for testing are selected by the engine and specified in the markup itself.
(See attached file: actf_web_accessibility_exerpt.xml)(See attached file: mozdom_validation.js)
Here is the JSON description of the same rules (which, of course, is not strictly JSON since JSON does not suppport functions but you get the idea).
(See attached file: sample_actf_rules-json.txt)
Notice that these rules could be registered to the YSlow engine with little modification. In particular, each rule in the arrays that correspond to a particular tag/node name would be registered, the definition of the validate function would need to be rewritten, and the function's logic would need to do node selection on its own. Since the ACTF validation engine would select nodes and rules appropriate for those nodes, no such logic is in the validate function. It is assumed that the element is of the type specified in the key (e.g. 'img', 'input'). Also, we are assuming (like YSlow) that these rules are invoked when the document is loaded but I could easily imagine other rulesets being invoked on the firing of other events. (Processing such a file is not a part of the engine at this time; my only intent is to show how the rules could be written in JSON-like notation.)
Two advantages to this approach over our current method of describing rules:
1. more familiar and readable than the rather cryptic markup we've put together for ACTF validation documents; also, because ACTF currently relies heavily upon the Java Reflection API to process validation documents, the validation document author/editor must have some knowledge of the underlying Java API that is being used (e.g. for web accessibility, its Java XPCOM)
2. in this form, rules could be directly injected into the browser; for instance, for the file, above, we could attach the execution of these rules directly to the onload event, which is (I assume) what YSlow does; the engine would still be present, but it would not execute the rules
Please feel free to ask questions - I know that this is probably an eye-full at first glance.
--> Mike Squillace
IBM Human Ability and Accessibility Center
Accessibility Tools Framework (ACTF) co-technical lead
http://www.eclipse.org/actf
W:512.286.8694
M:512.970.0066
External: http://www.ibm.com/able
Internal: http://w3.ibm.com/able
Aaron M Leventhal/Cambridge/IBM
11/18/2008 07:29 AM |
|
One weakness I see with this system is that the rules don't work well for dynamically inserted content. For example, AJAX may be used to add content to a page. That content may just be a small portion of a page, but needs to be tested for an <img> with no alt. The rule below needs to go through all the img's in the page again. Perhaps the lint rule should take a subtreeRootNode optional argument?
The ACTF approach had been to define rules and rulesets in XML. That may not be as flexible as script, but may have other advantages.
Sandy or Mike, do you have any perspective on the advantages of writing rules declaratively as opposed to using an API and writing lint methods?
- Aaron
"Victor Tsaran" ---11/18/2008 02:18:31 AM---I really like this approach (and the lightness of it) because the rulesets could be hosted on some C From: | "Victor Tsaran" <vts...@yahoo-inc.com> |
To: | "Stoyan Stefanov" <sto...@yahoo-inc.com>, "Jon Gunderson" <jon...@illinois.edu> |
Cc: | Aaron M Leventhal/Cambridge/IBM@IBMUS, Richard Schwerdtfeger/Austin/IBM@IBMUS, "Sandy Foltz" <sfo...@gmail.com> |
Date: | 11/18/2008 02:18 AM |
Subject: | RE: YSlow rules for analyzing performance question |
I really like this approach (and the lightness of it) because the
rulesets could be hosted on some CDN and be available to anybody who
installs Yslow.
Thoughts?
-----Original Message-----
From: Stoyan Stefanov
Sent: Monday, November 17, 2008 5:02 PM
To: Victor Tsaran; 'Jon Gunderson'
Cc: 'Aaron M Leventhal'; 'Richard Schwerdtfeger'; 'Sandy Foltz'
Subject: RE: YSlow rules for analyzing performance question
Hi guys,
YSlow2 is not yet stable enough, although the extensibility APIs are
pretty final. I wouldn't encourage starting development at this point,
but these rules give us a good case to test out APIs, instead of making
up extensions.
To give you an idea, YSlow2 will have the static methods
YSLOW.registerRule()
YSLOW.registerRuleset()
So anyone can create a blank Firefox extension, and use the YSLOW.*
functions, for example, let's say a rule that tests if all images have
alt attributes:
YSLOW.registerRule({
name: 'Use ALT attributes',
id: 'wai_alt',
url: 'http://more.info/here',
lint: function(doc, components) {
var offenders = []; // will store offending img tags
var imgs = doc.getElementsByTagName('img');
// loop imgs, check alt attribute
// once done, return a result object
return {
score: score: 100 - offenders.length * 5, // each offender 5
points
message: (offenders.length > 0) ? 'use ALT' : '',
components: offenders
}
}
});
This way a new rule will be added in the YSlow pool of rules.
Now using YSLOW.registerRuleset() you define a set of rules and their
relative weight/significance from those in the pool. The new ruleset
will be available through a dropdown of all rulesets defined in YSLow
(UI not yet finalized ;))
So all that's needed are calls to define rules and rulesets, YSLow will
take care of the rest - gathering components, calling lint() methods,
presentation of the results, and so on.
Since the rules are defined in a separate extension, they can live a
life independent of the YSlow releases.
Hope this clarifies the idea.
Should you decide to go on a different path (independent of YSlow2) and
start a new extension, do not hesitate to contact me, I can help with
the extension development (and promotion/evangelizing) as I feel
strongly that we need an accessibility tool similar to YSlow.
Yet another approach is to start a new extension now but keep the rules
part decoupled from the UI and the FF-dependent code, so later the rules
can also be ported as YSlow2 rules.
Best,
Stoyan
p.s. You can take a look at my extension-generator tool that allows me
to start quickly with new extensions: http://tools.w3clubs.com/ext/
-----Original Message-----
From: Victor Tsaran
Sent: Monday, November 17, 2008 4:11 PM
To: Jon Gunderson; Stoyan Stefanov
Cc: Aaron M Leventhal; Richard Schwerdtfeger; Sandy Foltz
Subject: RE: YSlow rules for analyzing performance question
Hello Stoyan and Jon,
These are the same rules that I had in mind when we spoke last time.
Some of them will be easier to implement than others.
Is YSlow2 API stable enough for others to start writing extensions for
it?
Thanks,
Victor
-----Original Message-----
From: Jon Gunderson [mailto:jon...@illinois.edu]
Sent: Monday, November 17, 2008 2:58 PM
To: Stoyan Stefanov
Cc: Aaron M Leventhal; Richard Schwerdtfeger; Sandy Foltz; Victor Tsaran
Subject: RE: YSlow rules for analyzing performance question
Stoyan,
Thank you for your response.
1. Here are some of the types of rules we would like to implement:
http://html.cita.uiuc.edu/nav/title/title-rules.php
http://html.cita.uiuc.edu/nav/heading/heading-rules.php
http://html.cita.uiuc.edu/nav/menu/menu-rules.php
http://html.cita.uiuc.edu/nav/form/form-rules.php
http://html.cita.uiuc.edu/nav/lang/lang-rules.php
http://html.cita.uiuc.edu/nav/link/link-rules.php
http://html.cita.uiuc.edu/nav/dtable/dtable-rules.php
These should give you an idea of some of the rules we wouldl like to
check static HTML for WCAG 2.0 and Section 508 conformance.
2. A new set of rules is being developed to support Accessible Rich
Internet Applications (ARIA). These are still under development and the
group is looking for existing code that can be used to implement the
rules in Firebug.
ARIA Spec:
http://www.w3.org/TR/wai-aria
3. Is there a chance we can get access to YSlow2 to look at how it can
help implement these rules?
Thanks,
Jon
---- Original message ----
>Date: Mon, 17 Nov 2008 13:59:34 -0800
>From: "Stoyan Stefanov" <sto...@yahoo-inc.com>
>Subject: RE: YSlow rules for analyzing performance question
>To: "Jon Gunderson" <jon...@illinois.edu>
>
>Hi Jon,
>
>I'm Stoyan, YSlow developer and YSlow 2 architect.
>
>The new YSlow 2 (to be released in the coming months) has an extensible
>API and allows for people to create new Rules and "rulesets" (sets of
>rules) very easily. In addition to the performance checks in YSLow you
>would be able to create a set of accessibility checks by just writing
>some JavaScript. Then you can distribute this independently of yslow,
>as a separate extension.
>
>If you have the rules you want to test for, or a URL that describes
>them, you can send them to me and I will volunteer to create such an
>extension.
>
>But again, this is dependent on the YSlow2 release. The other option is
>to have a yslow-independent Firefox extension but in this case you'll
>have to do the heavy lifting of discovering page components, their HTTP
>request/response headers, UI of the extension and so on. YSlow2 will
>provide this framework and heavy lifting.
>
>Best,
>Stoyan
>
>
>
>-----Original Message-----
>From: Jon Gunderson [mailto:jon...@illinois.edu]
>Sent: Monday, November 17, 2008 10:27 AM
>To: ys...@yahoo-inc.com
>Subject: YSlow rules for analyzing performance question
>
>Name: Jon Gunderson
>
>Email: jon...@illinois.edu
>
>Message:
>I am working with a group of people trying to develop an accessibility
>extension for Firebug to provide developers with information related to
>the accessibility of their web resources.
>
>We are looking for people who have already built some type of rules
>engine and reporting system for Firebug and was wondering if I could
>talk to someone about how you define and implement rules in YSlow.
>
>Thank you for your help,
>Jon
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility Disability Resources
and Educational Services
Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821
Voice: (217) 244-5870
WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
Aaron Leventhal
rules.
Is JSON the best approach to describe complex structures? For example,
if we want to ensure a correctly structured tree whenever there is a
role="tree", should that structure be described in a schema of some kind?
I note that Validator.nu does a (currently unsanctioned) HTML+ARIA
validation. It uses declarative syntax when it can, via RELAX NG and
Schematron. Should we borrow the rules developed there? If we do we can
combine code validation with accessibility testing, and reuse rules
developed by the community. Don't these things belong together?
- Aaron
> file: mozdom_validation.js)/
> Here is the JSON description of the same rules (which, of course, is
> not strictly JSON since JSON does not suppport functions but you get
> the idea).
>
> Leventhal/Cambridge/IBM
>
>
> *Aaron M Leventhal/Cambridge/IBM*
>
> 11/18/2008 07:29 AM
>
>
>
> To
>
> "Victor Tsaran" <vts...@yahoo-inc.com>
>
> cc
> "Jon Gunderson" <jon...@illinois.edu>, Richard
> Schwerdtfeger/Austin/IBM@IBMUS, "Sandy Foltz" <sfo...@gmail.com>,
> "Stoyan Stefanov" <sto...@yahoo-inc.com>, Michael A Squillace/Austin/IBM
>
>
> RE: YSlow rules for analyzing performance questionMichael A Squillace
> <Notes://D01ML605/85256B2F005958F3/38D46BF5E8F08834852564B500129B2C/DCABB99E0AD630A3CDB925257E6175B2>
>
>
>
> Thank you Stoyan, this is really helpful.
>
> One weakness I see with this system is that the rules don't work well
> for dynamically inserted content. For example, AJAX may be used to add
> content to a page. That content may just be a small portion of a page,
> but needs to be tested for an <img> with no alt. The rule below needs
> to go through all the img's in the page again. Perhaps the lint rule
> should take a subtreeRootNode optional argument?
>
> The ACTF approach had been to define rules and rulesets in XML. That
> may not be as flexible as script, but may have other advantages.
>
> Sandy or Mike, do you have any perspective on the advantages of
> writing rules declaratively as opposed to using an API and writing
> lint methods?
>
> - Aaron
>
>
>
> AM---I really like this approach (and the lightness of it) bec"Victor
> Tsaran" ---11/18/2008 02:18:31 AM---I really like this approach (and
> the lightness of it) because the rulesets could be hosted on some C
>
>
> "Victor Tsaran" <vts...@yahoo-inc.com>
>
> To:
> Cc:
> Schwerdtfeger/Austin/IBM@IBMUS, "Sandy Foltz" <sfo...@gmail.com>
>
> 11/18/2008 02:18 AM
> Subject:
> RE: YSlow rules for analyzing performance question
>
David
possible. Personally, I'm annoyed at having to run multiple tools on
my code.
David
>
> > cc
>
> > "Jon Gunderson" <jong...@illinois.edu>, Richard
> > Schwerdtfeger/Austin/IBM@IBMUS, "Sandy Foltz" <sfol...@gmail.com>,
> > Cc:
> > Aaron M Leventhal/Cambridge/IBM@IBMUS, Richard
>
> read more »
Michael A Squillace
I see no reason not to use both approaches, JSON and declarative markup or even others that folks might not yet have put forth. I just wanted to see what our ACTF rules might lok like encoded differently and discover if there were any initial impediments to doing so. I will look at validator.nu next week, as I now have a Windows build working with Henri's help.
--> Mike Squillace
IBM Human Ability and Accessibility Center
Accessibility Tools Framework (ACTF) co-technical lead
http://www.eclipse.org/actf
W:512.286.8694
M:512.970.0066
External: http://www.ibm.com/able
Internal: http://w3.ibm.com/able
Aaron Leventhal <aa...@moonset.net>
Sent by: free...@googlegroups.com 11/25/2008 08:15 AM
|
|
