Accessibility Verification of WWW Documents by an Automatic Guideline Verification Tool

Accessibility Verification of WWW Documents by an AutomaticGuideline Verification ToolYoshiaki Takata Takeshi Nakamura Hiroyuki SekiGraduate School of Information ScienceNara Institute of Science and Technology{y-takata,take-na,seki}@is.aist-nara.ac.jpAbstractSince the World Wide Web(WWW)is currently the princi-pal infrastructure used by the general public,web site cre-ators are required to build universally accessible sites.Ac-cessibility guidelines such as the Web Content Accessibil-ity Guidelines(WCAG)show the creators how to make ac-cessible web pages.Also,tools which automatically verify whether or not a given web page complies with the guide-lines are provided.Although those tools are useful,ap-plying them to any document format other than HTML or any guidelines other than WCAG is difficult,since these tools assume afixed set of guidelines(e.g.,WCAG)and a fixed document format(e.g.,HTML).That is,changing the built-in guidelines(e.g.,verifying whether a given document complies with the guidelines defined by their organization) requires modifying the tool.This paper proposes a simple and clear language for specifying guidelines,and discusses a verification tool which has the following characteristics.•A guideline specification is separated from the tool and can be easily modified.•An arbitrary XML document can be verified.•The tool can be used not only for accessibility guide-line verification but also for complex syntactic check-ing.We also present the verification results conducted on about3,000web pages of forty major organizations in the U.S.A.and Japan using our verification tool.1IntroductionAccessibility has been broadly recognized as a key issue in universal design.Universal accessibility of a content,either digital or not,means that everyone can read or listen to the content without difficulty.Especially,the World Wide Web (WWW)is currently the principal infrastructure to collect information not only for scientists or technologists but also for the general public.Thus,web site creators should make the information on their sites universally accessible to ev-eryone[10].Activities for improving web page accessibility di-verge to variousfields such as law,education,re-search/development and guidelines.Accessibility guide-lines show web site creators how to make web pages ac-cessible.For example,the World Wide Web Consortium (W3C)provides the Web Content Accessibility Guidelines (WCAG)[15],which consists of more than ninety check-points.Although these guidelines are useful,much effort is often needed in consulting the guidelines when writing web pages because the guidelines are concerned with var-ious aspects of web accessibility.Furthermore,designs which may cause accessibility problems are often over-looked since those designs may not affect the accessibility from the creators themselves.As a result,a large number of web sites which do not have sufficient accessibility still remain.For example,Ishikawa[3]examined the accessibil-ity of web pages of major organizations in the U.S.A.and Japan,and reported that the ratio of the pages which com-ply with Priority1checkpoints in WCAG to the total is only 35%.Therefore,if we have a tool that automatically verifies whether or not a given web page complies with the guide-lines,this will help the creators reduce the effort needed to make accessible web sites.Bobby[9,19],provided by the Center for Applied Special Technology(CAST),is one of such tools.Weblint[2],WebSAT[7]and LIFT[14]are also known as tools for analyzing web pages.Although those tools are useful,applying them to any document format other than HTML or any guidelines other than WCAG is difficult,since these tools assume afixed set of guidelines(e.g.,WCAG)and afixed document for-mat(e.g.,HTML).For example,WCAG contains a guide-line“Provide an alternative text for every image,”applicableto any document format which can contain images.How-ever,currently available tools assume an HTML document and interpret the guideline as“Provide the ALT attribute for every IMG element.”Thus,changing the built-in guide-lines requires modifying the tool.Furthermore,verifying whether or not a given document complies with the guide-lines defined by their organization is highly desirable.In this paper,we define a simple language called SGSL (Simple Guideline Specification Language)for specifying guidelines.SGSL is afirst-order language which includes XPath[16]asfirst-order atomic predicates,and has suf-ficient expressive power for specifying guidelines.We then present a method of automatically verifying a given XML document with respect to given guidelines written in SGSL:Guidelines in SGSL is compiled into an XSLT stylesheet[17],and verification of the XML document is performed by an arbitrary XSLT processor with the com-piled XSLT stylesheet.Based on the method,we have im-plemented a verification tool.The paper provides verifica-tion results conducted by the tool on about3,000web pages of forty major organizations in the U.S.A.and Japan.The contributions of the paper are summarized as follows.•Since a guideline specification is separated from a verification tool,it contributes the availability of the tool. For example,when we would like to use guideline G B rather than the current G A,we only have to change the guideline specification from G A to G B without modifying the tool it-self.Since guidelines are formally defined in SGSL and provided to the verification tool,one can clearly understand which properties are taken into consideration by the tool.•An arbitrary XML document can be verified.Since XML is a meta-language which can represent various doc-ument formats including HTML,our verification method is applicable to a sufficiently large set of documents.Fur-thermore,SGSL can concisely describe properties which an XML document should satisfy.•Verification using the SGSL tool is not limited to accessibility guidelines.For example,the SGSL tool can be used for verifying whether a given official document(e.g., a grant application form)complies with requirements such as:“entry A is mandatory”and“applicant name in page one should be the same as project organizer in page six.”The rest of the paper is organized as follows.In section 2,the syntax and semantics of SGSL is defined and a few WCAG checkpoints are specified in SGSL.The expressive power of SGSL is also discussed in section2.In section 3,we describe our verification tool.The SGSL compiler,which is the heart of the tool,is explained in some detail.As an example of automatic verification using the tool,wepresent the verification result for a web page of U.S.A.government.In section4,the experiment which has beenconducted for about3,000web pages of forty major organi-zations is described.Section5concludes the paper.2Guideline specification language 2.1Design principlesSimilar to currently available tools,SGSL is designed sothat one can specify checkpoints based on the syntax ofa document(e.g.,“Provide the ALT attribute for everyIMG element”),leaving a human user to verify the docu-ment with respect to checkpoints such as“Use clearest andsimplest language appropriate for a site’s content.”Thereare several syntax definition languages for XML,such asXML DTD(Document Type Definition)and XML Schema,which are based on context-free grammar.However,thoselanguages do not have sufficient power to describe a guide-line specification.For example,they cannot represent thecheckpoint,“Do not use the same link phrase more thanonce when the links point to different URLs”in WCAG.Toovercome the problem,SGSL is defined as an extension ofXPath(XML Path Language)[16].Each XML documentcan be represented as a tree structure,and an XPath expres-sion specifies a node or a set of nodes in the tree.A booleanexpression on nodes or sets of nodes can also be written inXPath.However,the above-mentioned checkpoint requiresthat a guideline specification language can express a con-dition such that“a given boolean expression is satisfied byevery node in a given set of nodes,”which cannot be writ-ten in XPath.SGSL is defined to be able to denote suchconditions by extending the syntax of XPath.2.2Syntax and semanticsThe syntax of SGSL is shown in Figure1.A guide-line specification is afinite set of checkpoints.Let d bea document to be verified and let f,f1,...be arbitrary boolean expressions.As shown in Figure1,a checkpointis either a boolean expression f1or an expression of theform if f2then warn(String).In the former case,iff1does not hold for a given document d,then a warn-ing is emitted with the checkpoint identifier.In the lat-ter case,if f2holds for d,then the warning specified asString is emitted with the checkpoint identifier.In otherwords,f1is a condition necessary for a document to sat-Checkpoint::=BooleanExpression|if BooleanExpression then warn(String) BooleanExpression::=XPathBooleanExpression|every Variable in NodeSet satisfiesBooleanExpression |some Variable in NodeSet satisfiesBooleanExpression |let Variable:=XpathExpression inBooleanExpression |BooleanExpression Bop BooleanExpression|not BooleanExpressionNodeSet::=XPathNodeSetExpressionBop::=implies|or|andFigure1:Syntax of SGSL.Table1:Classification of WCAG checkpoints by Bobby.Full Partial PartialOnceAskOnceTotalPriority17164229Priority213128740Priority3548522Total2532201491 isfy the checkpoint,while f2is a condition for the verifica-tion tool to emit the specified warning for the checkpoint.A boolean expression every$v in s satisfies f is true if and only if f holds for every node v in the node set specified by XPath expression s.Likewise,an expression some$v in s satisfies f is true if and only if there exists a node v in the node set specified by XPath expres-sion s.In f,one can use variables v and pos v.The latter denotes the position of the value bound to v in s.An expres-sion let$v:=p in f binds the value of XPath expression p to variable v in f.2.3Sample specifications in SGSLUsing SGSL,some guidelines can be simply specified.For example,all the WCAG checkpoints considered in Bobby have been specified in SGSL.The number of the check-points is91.In the following,we will show some WCAG checkpoints specified in SGSL.Bobby classifies WCAG guidelines into four categories according to their conformation level,as shown in Table1. Each category is further divided into three groups accord-ing to priority.For example,a checkpoint with Priority one describes a basic(necessary)condition for a document to be accessible by everyone.More specifically,there are peo-ple who cannot access a document which does not satisfy a checkpoint with Priority one.The behavior of Bobby for a checkpoint in each category is as follows.Checkpoint numbers referred to in the exam-ples are those specified in WCAG and Bobby.Full:Bobby automatically verifies a document for the checkpoint.Ex.“Provide alternative text for all images(check-point1.1-1).”Partial:Bobby extracts document fragments which may not satisfy the checkpoint,and shows the line numbers of them in the HTML sourcefile.Bobby leaves to the user the decision whether or not these fragments sat-isfy the checkpoint.Ex.“If you use color to convey information,make sure the information is also represented another way (checkpoint2.1).”Partial Once:The same as“Partial”except that the checkpoint is concerned with the whole document and thus Bobby does not show a line number.Ex.“Use style sheets to control layout and presenta-tion wherever possible(checkpoint3.3).”Ask Once:Bobby does not verify a document for the checkpoint and shows a predetermined caution to a user.Ex.“Use the simplest and most straightforward lan-guage that is possible(checkpoint14.1).”(Ex1)“Provide the ALT attribute for every IMG element. (Checkpoint1.1-1,Full)”every$x in//img satisfies$x/@alt Since a boolean expression is specified as a checkpoint,this expression denotes a condition for a given document d to satisfy.That is,d satisfies this checkpoint if and only if every img element$x in d satisfies$x/@alt.The ex-pression$x/@alt is the XPath boolean expression which means that every img element in the set bound to variable x has an alt attribute.(Ex2)“If ALT text>150characters,consider providing a separate description.(Checkpoint1.1-6,Partial)”if some$x in//*/@alt satisfiesstring-length($x)>150then warn("consider providing aseparate description")Since an expression of the form if f2then warn(String) is specified as a checkpoint,the warning is emitted if and only if f2holds.That is,if(and only if)there exists an alt attribute of which length exceeds150in a given document, then the warning“consider providing a separate descrip-tion”is emitted.Function string-length is the XPath 1.0built-in function which returns the number of characters appearing in the string given as an argument.(Ex3)“Do not use the same link phrase more than once when the links point to different URLs.(Checkpoint13.1-4,Full)”every$x in//a satisfiesevery$y in//a satisfies$x/@href!=$y/@href implies$x!=$yA given document d satisfies this checkpoint if and only if each pair of a attributes$x and$y in d satisfies$x/@href!=$y/@href implies$x !=$y.The last expression means that if the href at-tribute values of a elements bound to variables x and y are different from each other,then a element values(link phrases)bound to x and y are also different from each other. (Ex4)“Nest headings properly.(Checkpoint3.5-1,Full)”let$h:=//*[self::h1|self::h2|self::h3|...|self::h6] in every$x in$h satisfies(($x/self::h1and$pos_x<count($h))implies$h[$pos_x+1][self::h1|self::h2]) and(($x/self::h2and$pos_x<count($h))implies$h[$pos_x+1][self::h1|self::h2|self::h3])and(($x/self::h3and$pos_x<count($h))implies$h[$pos_x+1][self::h1|self::h2|...|self::h4]) and(($x/self::h4and$pos_x<count($h))implies$h[$pos_x+1][self::h1|self::h2|...|self::h5]) Variable pos x denotes the position(positive integer) of the node bound to variable x in the(ordered)set h of h1,h2,...,h6elements.For example,subexpres-sion($x/self::h1and$pos x<count($h)) implies$h[$pos x+1][self::h1|self::h2] means that if the(pos x)th element in the set h is an h1 element,then the(pos x+1)th element in h is either an h1element or an h2element.2.4Expressive power of SGSLSeveral studies(e.g.,[4,8,11])has been conducted on the expressive power of query languages for tree-structured data,by usingfirst-order logic(FO)and its extension.In FO,an XML document t is modeled by a set dom(t)of node positions and the vocabulary{E,<,≺,(Oσ)σ∈Σ,(val a)a∈A} of relations and a function[8,12].E,<and≺are binaryrelations over dom(t)which represent an edge relation(be-tween a parent and a child),an ordering on siblings,and a descendant relation,respectively.Σis the set of element names appearing in t,and Oσis a unary relation on dom(t) such that Oσ(u)if and only if the label of u isσ.A is the set of attribute names appearing in t,and val a is a function from a node u to the value of the attribute a of u.D denotes the domain of attribute values.An atomic FO formula is of the form E(x,y),x<y,x≺y,Oσ(x),x=y,val a(x)=val b(y), or val a(x)=d where a,b∈A and d∈D.An FO formula consists of atomic formulas,boolean connectives andfirst-order quantification over dom(t).An expression in a core fragment of XPath with-out the built-in functions can be represented by an FO formula[8].For example,an XPath node set expres-sion p:=//body//img[@alt]is represented by an FO formulaφ(x):=∃y(y≺x∧O body(y)∧O img(x)∧¬(val alt(x)=⊥))with a free variable x;i.e.,φ(x)=true if and only if a node x belongs to the node set represented by p.Since SGSL consists of XPath and thefirst-order quan-tification(i.e.,every and some expressions),an SGSL ex-pression can be represented by an FO formula if its XPath subexpressions can be represented by FO formulas. Although we conjecture that SGSL is more expres-sive than XPath,difference between the expressive power of SGSL and XPath is not clear at present.For ex-ample,(Ex1)in section2.3can also be represented as not(//img[not(@alt)]),which is an XPath expres-sion using the built-in function not.In general,an SGSLFigure2:Structure of the verification tool. expression which consists of at most one quantification(i.e.,every or some)can also be written in XPath.To show the difference between XPath and SGSL is a future work.3Verification tool3.1OverviewWe have implemented a verification tool based on SGSL. The tool takes an XML document and a guideline specifi-cation in SGSL as input,and generates a report of the ver-ification(see Figure2).We use XSLT1.0(XSL Transfor-mations)[17],which is a language for specifying translation rules from an XML document into another XML document. XSLT includes XPath as a sub-language and has functions for value binding to variable and for iteration,which are useful for implementing SGSL.The tool consists of an SGSL compiler and an XSLT pro-cessor.The SGSL compiler translates a given guideline specification S SGSL into an XSLT stylesheet S XSLT.S XSLT defines a translation from an input XML document d into an XML document representing the verification results on d with respect to S SGSL.The XSLT processor executes this translation for d.The SGSL compiler has been im-plemented in Java.MSXSL[5]and Xalan[1]are used as XSLT processors.The translation algorithm from SGSL into XSLT,de-scribed in section3.2,is similar to the translation algorithm from XQuery into XSLT proposed in[6].Since SGSL can be seen as a subset of XQuery1.0(XML Query Lan-guage)[18],our algorithm is simpler than the algorithm in[6].Alternatively,the SGSL compiler would be imple-mented by using an implementation of XQuery.However, only a working draft of XQuery is provided,and no suffi-cient implementation of XQuery is currently available. 3.2Implementation of SGSL using XSLT Figure3is an XSLT stylesheet(i.e.,a translation specifica-tion written in XSLT)which the SGSL compiler generates from the guideline specification of(Ex1)in section2.3.We refer to the guideline specification as S1-SGSL and the gen-erated XSLT stylesheet as ing them,we briefly describe the XSLT stylesheet which implements a guideline specification in SGSL.Each translation rule in an XSLT stylesheet is called a template.S1-XSLT consists of four templates.The first template(lines5–9)is a bootstrap and becomes ef-fective just when S1-XSLT is applied to an XML docu-ment.The bootstrap simply calls another template named GL1-f0(lines10–25)and puts the result of GL1-f0un-der a report element.GL1-f0evaluates the boolean expression in S1-SGSL using GL1-f1(lines26–45)and GL1-f2(lines46–54),and puts either a passed ele-ment or a warn element into the resultant XML docu-ments.The boolean expression in S1-SGSL has two subex-pressions:f1=every$x in//img satisfies f2 and f2=$x/@alt.GL1-f1and GL1-f2evaluate f1and f2,respectively.Each template which evaluates a subexpression f gener-ates a string1if f is true,and generates the empty string if f is false.For example,template GL1-f2evaluates the subexpression f2=$x/@alt and if the result is true, then it generates a string1.GL1-f1is slightly more ing xsl:for-each element,it calls GL1-f2 for each x in the node set specified by//img.Since the xsl:call-template element(lines30–35)which calls GL1-f2is a descendant of a xsl:variable element (lines29–36),the result of GL1-f2is stored in the vari-able named return and is not put into the resultant XML document.If return=1,i.e.,f2=false for the current x,then GL1-f1appends a string0to variable result. Finally,GL1-f1generates a string1if result is empty, i.e.,there is no x for which f2=false.Subexpressions of the other types such as some-in-satisfies and let-in can be evaluated by similar templates.3.3SGSL compilerWe implemented an SGSL compiler in Java,which trans-lates SGSL into XSLT in the way described in section3.2.1:<?xml version="1.0"?>2:<xsl:stylesheet version="1.0"3:xmlns:xsl="..."4:xmlns:html="...">5:<xsl:template match="/">6:<report>7:<xsl:call-template name="GL1-f0"/>8:</report>9:</xsl:template>10:<xsl:template name="GL1-f0">11:<xsl:variable name="return">12:<xsl:call-template name="GL1-f1"/> 13:</xsl:variable>14:<xsl:choose>15:<xsl:when test="string($return)=1"> 16:<passed guideline="1"/>17:</xsl:when>18:<xsl:otherwise>19:<warn guideline="1">20:Provide alternative text for all 21:images.22:</warn>23:</xsl:otherwise>24:</xsl:choose>25:</xsl:template>26:<xsl:template name="GL1-f1">27:<xsl:variable name="result">28:<xsl:for-each select="//html:img"> 29:<xsl:variable name="return">30:<xsl:call-template name="GL1-f2"> 31:<xsl:with-param name="x"32:select="."/> 33:<xsl:with-param name="pos_x" 34:select="position()"/> 35:</xsl:call-template>36:</xsl:variable>37:<xsl:if test="string($return)!=1"> 38:<xsl:text>0</xsl:text>39:</xsl:if>40:</xsl:for-each>41:</xsl:variable>42:<xsl:if test="not(string($result))"> 43:<xsl:text>1</xsl:text>44:</xsl:if>45:</xsl:template>46:<xsl:template name="GL1-f2">47:<xsl:param name="x"/>48:<xsl:param name="pos_x"/>49:<xsl:variable name="result"50:select="$x/@alt"/>51:<xsl:if test="$result">52:<xsl:text>1</xsl:text>53:</xsl:if>54:</xsl:template>55:</xsl:stylesheet>Figure3:Generated XSLT stylesheet.<guideline id="1"><title>Provide alternative text forall images.</title><expression><condition><every-expression variable="x"select="//html:img"> <xpath-expressionselect="$x/@alt"/> </every-expression></condition></expression></guideline>Figure4:XML version of a guideline specification. The compiler requires a user to input a guideline specifica-tion written in an XML version of SGSL shown in Figure4. Thefigure is the XML version of the above-mentioned S1-SGSL.In the XML version of SGSL,the boolean expres-sion of the checkpoint is represented by the condition element and its descendants;i.e.,the subtree of the speci-fication in XML rooted by the condition element rep-resents the parse tree of the boolean expression in SGSL. This XML version of SGSL allows us to use an XML parser for parsing a guideline specification,and thus simplifies the implementation of the compiler.Our SGSL compiler uses Xerces[1]as an XML parser.Newly written codes of the compiler are about700lines.3.4Verification exampleAs mentioned in section2.3,we wrote all of the ninety-one WCAG checkpoints which Bobby takes into considera-tion in SGSL.We verified whether the top page of White House(February2,2003)satisfied these WCAG check-points using the verification tool.Since the page was in HTML format,we translated the page into an XHTML doc-ument(35K bytes)by JTidy[13].All the WCAG check-points(40K bytes)written in SGSL were translated into an XSLT stylesheet(161K bytes)by the SGSL compiler.The time need for compilation was about three seconds.The ob-tained XSLT stylesheet and the White House top page were processed by MSXSL,an XSLT processor,and the verifi-cation report were generated withinfive seconds.Figure5 shows a part of the verification report written in XML.For each checkpoint,a passed element is generated if the doc-ument satisfies the checkpoint,and a warn element is gen-erated otherwise.These two elements have the checkpoint number as an attribute.A warning message is included as the contents of a warn element.From Figure5,we can see the following properties of the input document:<?xml version="1.0"encoding="UTF-8"?> <report xmlns:html="..."><warn guideline="GL1.1-1">Provide alternative text for allimages.</warn><passed guideline="GL1.2"/><warn guideline="GL2.2">Check that the foreground andbackground colors contrastsufficiently with each other.</warn><warn guideline="GL3.4">Use relative sizing and positioning(%value)rather than absolute(pixels).</warn><warn guideline="GL5.5-1">Provide a summary for tables.</warn><warn guideline="GL6.1">If stylesheets are ignored orunsupported,are pages stillreadable and usable?</warn><warn guideline="GL13.1-4">Don’t use the same linkphrase morethan once when the links point todifferent URLs.</warn></report>Figure5:Result of the verification.•Checkpoint1.1-2(see(Ex1)in section2.3)is not sati-fied.A waning is emitted since the document contains an img element which has no alt attribute.•Checkpoint1.2is satisfied.•Checkpoint2.2is not satisfied.A warning which calls attention to the foreground and background colors con-trast is emitted.This warning is produced whenever a document simultaneously specifies the foreground and background colors.•Checkpoint3.4is not satisfied since the document con-tains a width attribute whose value is specified by an absolute value(pixels).•Checkpoint5.5-1is not satisfied since the document contains a table element which has no summary attribute.•Checkpoint13.1-4(see(Ex3)in section2.3)is not sat-isfied since the document uses the same link phrase for two a elements which point to different URLs.4Experiments4.1OverviewWe conducted an experiment which verifies the accessibil-ity of about3,000existing web pages by our verification tool.The experiment was designed along the report of Ishikawa[3]:Major sites of governments and companies in the U.S.A.and Japan(10sites for each and40sites in total)were chosen.The set of chosen sites are the same as in[3].For each site,the top page and the pages to which the top page has a link were collected on January,2003. These pages in HTML format were translated into XHTML documents by JTidy[13].Among ninety-one WCAG checkpoints,we have selected the seven checkpoints which are specified as Priority one by WCAG and specified as Full conformation by Bobby(see Table1).The original description and its translation into SGSL are listed in Tables2and3,respectively.Finally,the obtained XHTML documents were verified with respect to the seven WCAG checkpoints by our tool.A page which satisfies all the seven checkpoints is called passed and a page which does not satisfy at least one of the seven checkpoints is called not passed.We used Xalan as an XSLT processor in this experiment.Table6:The number of pages which do not satisfy each checkpoint.Checkpoint number1.1-1 1.1-2 1.1-3 1.1-4 1.1-10 6.212.1Subtotal ernment2056321217 Companies78210217838533481439 Subtotal9881021843883549165660%1%0%10%24%2%3%100% Japan Government1747385169 Companies5521785132188965 Subtotal7261792135273123459%0%0%1%7%11%22%100% Total1714112191480170322289059%0%0%7%17%6%11%100%Table2:WCAG guidelines with Priority one and Full con-formation[15].TitleGuideline1.Provide equivalent alternatives to audi-tory and visual content1.1-1Provide alternative text for all images.1.1-2Provide alternative text for each APPLET.1.1-3Provide alternative content for eachOBJECT.1.1-4Provide alternative text for all image-typebuttons in forms.1.1-10Provide alternative text for all image maphot-spots(AREAs).Guideline6.Ensure that pages featuring new technolo-gies transform gracefully6.2Each FRAME must reference an HTMLfile. Guideline12.Provide context and orientation infor-mation12.1Give each frame a title.4.2Results and discussionsResults of the experiment are summarized in Tables4and 5.For company sites,the rate of the passed pages to the total is about20%in both the U.S.A.and Japan.This rate is lower than the rate for government sites,and it suggests that design consideration for accessibility in companies may be less sufficient than governments.However,there are a few government sites where the rate of the passed pages to the total is less than10%both in the U.S.A.and Japan.Sum-marizing,the rate of the passed pages to the total is about 30%(894pages are passed and2,039pages are not passed). In Figure6,we show the number of pages which do not satisfy each checkpoint.From thefigure,we know that among the pages which are not passed,the rate of the pages which do not satisfy checkpoint1.1-1to the total is about 60%.As mentioned before,this experiment has been designed and conducted along with Ishikawa’s report[3]in2001, which reports that the rate of the number of passed docu-ments to the total is35%[3].This suggests that accessibil-ity of existing web documents is still not sufficient even for world’s major sites.Note that Ishikawa used Bobby(2001 version)for the experiment.The behavior of Bobby,how-ever,is being modified to interpret WCAG guidelines as accurately as possible.Since the SGSL specification was written by referring to Bobby in2002version,there exist a few documents which was passed in Ishikawa’s experi-ment and was not passed in our experiment.For example, Checkpoint1.1-1(Provide the ALT attribute for every IMG element)was interpreted as“every img element x has alt attribute”by Bobby(2001version).In addition to this con-。