Html - CodeAnt AI

<li> and <dt> item tags should be in <ul>, <ol> or <dl> container tags

Using a <li> or <dt> item tag outside of a <ul>, <ol> or <dl> one does not make sense and indicates a bug.

<li>Apple</li>          <!-- Noncompliant -->
<li>Strawberry</li>     <!-- Noncompliant -->

<li>Apple</li>          <!-- Noncompliant -->
<li>Strawberry</li>     <!-- Noncompliant -->

<dt>Apple</dt>          <!-- Noncompliant -->
<dt>Strawberry</dt>     <!-- Noncompliant -->

Table cells should reference their headers

If a `<td> cell has a headers attribute, it should reference only IDs of headers in the same column and row.

Note that it is usually better to use scope attributes of <th> headers instead of headers attribute. headers attribute requires you to list every corresponding <th> header’s id, which is error-prone and makes the code less maintainable. See W3C WAI Web Accessibility Tutorials for more information.

If your table is too complex, it might be better to split it into multiple small tables as it improves both readability and maintainability.

This rule raises an issue when the headers attribute of a <td>` cell contains IDs which don’t belong to a header in the same row or column.

<table border="1">
<caption>
Rental price
</caption>
<thead>
<tr>
    <td></td>
    <th id="small" scope="col">
        Small car
    </th>
    <th id="big" scope="col">
        Big Car
    </th>
</tr>
</thead>
<tbody>
<tr>
    <th id="paris" class="span" colspan="3" scope="colgroup">
        Paris
    </th>
    </tr>
    <tr>
    <th headers="paris" id="day1">
        1 day
    </th>
    <td headers="paris day1 big"> <!-- Noncompliant, referencing the column "big" instead of "small" -->
        11 euros
    </td>
    <td headers="berlin day1 big"> <!-- Noncompliant, there is no header with id "berlin" -->
        50 euros
    </td>
    </tr>
</tr>
</tbody>
</table>

<!DOCTYPE> declarations should appear before <html> tags

The `<!DOCTYPE> declaration tells the web browser which (X)HTML version is being used on the page, and therefore how to interpret the various elements.

Validators also rely on it to know which rules to enforce.

It should always preceed the <html>` tag.

<html>  <!-- Noncompliant -->
...
</html>

Tables used for layout should not include semantic markup

Tables used for layout should not include semantic markup, such as `<th> elements, as it can confuse assistive technologies. At best this information is ignored by screen readers and makes the code less maintainable. However it can also confuse some screen readers and reduce the web page accessibility.

This rule raises an issue when a <table> element containing the role attribute set to “presentation” or “none” also contains any of:

a <caption> element
a <th> element
a non-empty summary attribute
an <td> element with a headers or scope` attribute

<table role="presentation" summary="bla"> <!-- Noncompliant -->
<caption>People</caption> <!-- Noncompliant -->
<tr>
<td></td>
<th>Name</th> <!-- Noncompliant -->
<th id="myid1">Age</th> <!-- Noncompliant -->
</tr>
<tr>
<td scope="row">1</td> <!-- Noncompliant -->
<td>John Doe</td>
<td>24</td>
</tr>
<tr>
<td id="myid2">2</td>
<td headers="myid1 myid2">Alice Doe</td> <!-- Noncompliant -->
<td>54</td>
</tr>
</table>

<title> should be present in all pages

Titles are important because they are displayed in search engine results as well as the browser’s toolbar.

This rule verifies that the <head> tag contains a <title> one, and the <html> tag a <head> one.

<html>         <!-- Non-Compliant -->

<body>
...
</body>

</html>

<th> tags should have id or scope attributes

Associating `<table> headers, i.e. <th> elements, with their <td> cells enables screen readers to announce the header prior to the data. This considerably increases the accessibility of tables to visually impaired users.

There are two ways of doing it:

Adding a scope attribute to <th> headers.
Adding an id attribute to <th> headers and a headers attribute to every <td> element.

It is recommended to add scope attributes to <th> headers whenever possible. Use <th id=”…”> and <td headers=”…”> only when <th scope=”…”> is not capable of associating cells to their headers. This happens for very complex tables which have headers splitting the data in multiple subtables. See W3C WAI Web Accessibility Tutorials for more information.

Note that complex tables can often be split into multiple smaller tables, which improves the user experience.

This rule raises an issue when a <th> element has neither id nor scope` attributes set.

<table border="1">
<caption>Contact Information</caption>
<tr>
<td></td>
<th>Name</th>                                          <!-- Non-Compliant -->
<th>Phone#</th>                                        <!-- Non-Compliant -->
<th>City</th>                                          <!-- Non-Compliant -->
</tr>
<tr>
<td>1.</td>
<th>Joel Garner</th>                                   <!-- Non-Compliant -->
<td>412-212-5421</td>
<td>Pittsburgh</td>
</tr>
<tr>
<td>2.</td>
<th>Clive Lloyd</th>                                   <!-- Non-Compliant -->
<td>410-306-1420</td>
<td>Baltimore</td>
</tr>
</table>

<strong> and <em> tags should be used

The `<strong>/<b> and <em>/<i> tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: <strong> and <em> have a semantic meaning whereas <b> and <i> only convey styling information like CSS.

While <b> can have simply no effect on a some devices with limited display or when a screen reader software is used by a blind person, <strong> will:

Display the text bold in normal browsers
Speak with lower tone when using a screen reader such as Jaws

Consequently:

in order to convey semantics, the <b> and <i> tags shall never be used,
in order to convey styling information, the <b> and <i>` should be avoided and CSS should be used instead.

<i>car</i>             <!-- Noncompliant -->
<b>train</b>         <!-- Noncompliant -->

Scriptlets should not be used

Just because you can do something, that doesn’t mean you should, and the use of full-fledged Java in a JSP or JSF falls into that category.

Beside the fact that such code isn’t resuable, testable, maintainable or OO-inheritable, using Java in such client-side pages can leave you incredibly vulnerable from a number of perspectives including security and resource management.

Instead, any heavy-duty logic should happen server-side in a full-fledged Java class. For lighter-weight functions, taglibs should be used.

This rule flags all uses of JSP declarations (<%! … %> and <jsp:declaration>…</jsp:declaration>) and scriptlets (<% … %>).

<%!  // Noncompliant
private Connection conn = null;

public void init() {
try {
  Class.forName("org.hsqldb.jdbcDriver" );
  conn = DriverManager.getConnection("jdbc:hsqldb:mem:SQL", "sa", "");
} catch (SQLException e) {
  getServletContext().log("Db error: " + e);
} catch (Exception e) {
getServletContext().log("System error: " + e);
}
}
%>
<%    // Noncompliant
Statement stmt = conn.createStatement();
ResultSet rs = null;
String query = StringEscapeUtils.escapeHtml4(query).replaceAll("'", "&#39");

try {
String sql = "SELECT PRODUCT, DESC, TYPE, PRICE " +
                 "FROM PRODUCTS" +
                 "WHERE PRODUCT LIKE '%" + query + "%'";
rs = stmt.executeQuery(sql);

String output = "";
int count = 0;
while (rs.next()) {
count++;
output = output.concat("<TR><TD>" + rs.getString("PRODUCT") + 
                              "</TD><TD>" + rs.getString("DESC") + 
                              "</TD><TD>" + rs.getString("TYPE") + 
                              "</TD><TD>" + rs.getString("PRICE") + "</TD></TR>\n");
}
if(count > 0){
%>
<TABLE border="1">
<TR><TD>Product</TD><TD>Description</TD><TD>Type</TD><TD>Price</TD></TR>
<%= output %>
</TABLE>
<%  // Noncompliant
}
} catch (Exception e) {
// ...

When parsing a script node, the browser treats its contents as plain text, and immediately finishes parsing when it finds the first closing `</script> character sequence.

As a consequence, nested script nodes are not possible, because all opening <script> tags found along the way are ignored.

Web browsers doesn’t support nested <script>…</script> elements. But there is no error in such case and browsers just close the first encountered <script> tag as soon as a closing </script>` tag is found along the way. So there is a big chance to display something totally unexpected to the end-users.

<script type="text/template">
<div>
Hello!
</div>
<script type="text/javascript">  <!-- Noncompliant -->
alert("Hi!");
</script>
</script>

Track lack of required an element with the required id

This rule allows you to make sure that each HTML page contains an element with your configured ID, regardless of element type. This rule is useful, for instance, if your design requires a placeholder to be present in each page, for example to dynamically insert a footer.

<div id="#footer">
...
</div>

Web pages should not contain absolute URIs

It is considered best-practice to use relative URLs in web pages to prevent having to update the addresses if the web address in use changes. Moreover, if some absolute URLs are missed in such a process, it will obviously impact the user experience.

<img src="http://www.myserver.com/smiley.gif" alt="Smiley face" height="42" width="42" />

<table> tags should have a description

In order to be accessible to visually impaired users, it is important that tables provides a description of its content before the data is accessed.

The simplest way to do it, and also the one recommended by WCAG2 is to add a `<caption> element inside the <table>.

Other technics this rule accepts are:

adding a concise description via aria-label or aria-labelledby attributes in the <table>.
referencing a description element with an aria-describedby attribute in the <table>.
embedding the <table> inside a <figure> which also contains a <figcaption>.
adding a summary attribute to the <table> tag. However note that this attribute has been deprecated in HTML5.

See W3C WAI Web Accessibility Tutorials for more information.

This rule raises an issue when a <table>` has neither of the previously mentioned description mechanisms.

<table> <!-- Noncompliant -->
...
<table>

JavaScript scriptlets should not have too many lines of code

Long pieces of JavaScript should be located in dedicated *.js source files. This makes maintenance of both the script and the pages that use it easier. Additionally, it offers some efficiencies in serving the files, since it takes better advantage of browser caching to only re-serve the parts of a web page that have actually changed.

<head>
...
<script type="text/javascript" language="JavaScript">  <!-- Noncompliant -->
function doTheThing(arg1) {
  ...
  ...
}

function doTheOtherThing(arg1) {
  ...
} 

function andSoOn() {
  ...
}
</script>
</head>

Track lack of required attributes

Flash animations should be embedded using the window mode

Browsers best support the `window mode for the wmode parameter, also in terms of accessibility.

As it is the default mode, it is acceptable to either not specify a wmode parameter altogether, or to set it explicitly to window`.

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="550" height="400">
<param name="movie" value="movie_name.swf" />
<param name="wmode" value="direct" />                              <!-- Non-Compliant -->
</object>

<embed src="movie_name.swf"
   width="550"
   height="400"
   wmode="direct"                                                                 <!-- Non-Compliant -->
   type="application/x-shockwave-flash"
   pluginspage="http://www.macromedia.com/go/getflashplayer" />

<html> element should have a language attribute

The `<html> element should provide the lang and/or xml:lang attribute in order to identify the default language of a document.

It enables assistive technologies, such as screen readers, to provide a comfortable reading experience by adapting the pronunciation and accent to the language. It also helps braille translation software, telling it to switch the control codes for accented characters for instance.

Other benefits of marking the language include:

assisting user agents in providing dictionary definitions or helping users benefit from translation tools.
improving search engine ranking.

Both the lang and the xml:lang` attributes can take only one value.

<!DOCTYPE html>
<html> <!-- Noncompliant -->
    <head>
         <title>A page written in english</title>
         <meta content="text/html; charset=utf-8" />
    </head>  


    <body>     
    ...   
    </body>
</html>

Track uses of disallowed elements

Heading tags should be used consecutively from H1 to H6

Heading tags are used by search engines and screen reader softwares to construct an outline of the page.

Starting at <h1> and not skipping any level eases this automatic construction.

<h2>My Title</h2>     <!-- Non-Compliant - h1 is not being used -->

<h3>My Sub Title</h3> <!-- Compliant -->

autocomplete should be set to off on input elements of type password

Most browsers automatically fill the content of input elements of type ‘password’ when this password has already been provided in the past.

Imagine that user B takes control of a machine belonging to a user A. Accessing a secured web site as user A is trivial for user B if form input elements are automatically filled in by the browser on the site’s login page.

HTML 5 specifies the ability to turn this functionality off on a field-by-field basis using the autocomplete attribute, but most modern browsers ignore it in favor of their own password management.

<input type="password" />

iframes should be sandboxed

HTML5 introduces the ability to restrict the permissions of content loaded into an `iframe. Simply adding the sandbox attribute to an iframe tag limits the iframe to simply loading the specified contents; no scripts will run, no popups will pop, and so on. You can re-enable additional functions individually by specifying them in the attribute’s value:

allow-forms - form submission
allow-popups - popups
allow-scripts - script execution
allow-pointer-lock - access to the “pointer lock” API
allow-same-origin - sandboxed content is marked as being from a different domain (even when it’s not). This attribute turns that off so that, for instance, the iframe content can access its site’s cookies.
allow-top-navigation - turns the target attribute of a tags back on

Following the principle of minimum privileges, this rule raises an issue for each iframe which does not have a sandbox` attribute.

<iframe src="https://platform.twitter.com/widgets/tweet_button.html"
    style="border: 0; width:130px; height:20px;">  <!-- Noncompliant -->
</iframe>

Track lack of required child elements

Links should not target # or javascript:void(0)

There are two ways to build a link that has the sole purpose of running JavaScript code. The goal of this rule is to ban such patterns in order to support browsing with JavaScript disabled.

<a href="#" onclick="alert('Clicked!'); return false;">Run JavaScript Code</a> <!-- Noncompliant -->
<a href="javascript:void(0)" onclick="alert('Clicked!'); return false;">Run JavaScript Code</a>  <!-- Noncompliant -->
<a id="inPageAnchor">Jump down the page to me</a>  <!-- Compliant -->

Assignments should not be made in boolean contexts

The assignment of a boolean variable inside the test of a control structure such as an if, while or for loop is almost always a mistake and should be corrected to avoid unexpected program results. In fact, even if it was done on purpose, it should be re-examined.

boolean b = false;
if ( b = m.getTrue()) { ... } // Noncompliant

while (b = getTrue()) { ... } // Noncompliant; unintentionally infinite

for (int i = 0; i < 10 && b = getTrue(); i++) { ... } // Noncompliant

Image tags should have width and height attributes

If the width and height attributes are set, the space required for the image is reserved immediately by the browser, even before it actually starts to load the image.

Without those attributes, the page layout constantly changes as images are loaded until they are all loaded, which can disorient users.

<img src="logo.png" alt="My Company" />                           <!-- Non-Compliant -->

Flash animations should be embedded using both <object> and <embed>

The `<object> tag is used by Internet Explorer 3.0 or later on Windows platforms or any browser that supports the use of the Flash ActiveX control. The <embed> tag is used by Netscape Navigator 2.0 or later, or browsers that support the use of the Netscape-compatible plug-in version of Flash Player.

When an ActiveX-enabled browser loads the HTML page, it reads the values set on the <object> and ignores the <embed> tag. When browsers using the Flash plug-in load the HTML page, they read the values set on the <embed> tag and ignore the <object>` tag.

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="100" height="100">      <!-- Non-Compliant -->
<param name="movie" value="movie_name.swf" />
</object>

<embed src="movie_name.swf"                                                                 <!-- Non-Compliant -->
   width="550"
   height="400"
   type="application/x-shockwave-flash"
   pluginspage="http://www.macromedia.com/go/getflashplayer" />

Disallowed taglibs should not be used

This rule checks that the disallowed tag libraries are not used.

<%@ taglib uri="http://java.sun.com/jstl/sql" prefix="prefixOfTag" > <!-- Noncompliant -->
<jsp:directive.taglib uri="http://java.sun.com/jstl/sql" prefix="prefixOfTag" /> <!-- Noncompliant -->

Track uses of disallowed child elements

Attributes should be quoted using double quotes rather than single ones

Attributes should be quoted using single quotes

JSF expressions should be syntactically valid

This rule allows to make sure that all JSF Expressions are syntactically correct.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:body>
 First name 
 <h:outputText value="#{user.firstName && @@}"/>   <!-- Noncompliant -->
</h:body>
</html>

Meta tags should not be used to refresh or redirect

Use of <meta http-equiv=“refresh”> is discouraged by the World Wide Web Consortium (W3C).

If a user clicks the ‘Back’ button, some browers will go back to the redirecting page, which will prevent the user from actually going back.

To refresh the page, a better alternative is to use Ajax, to refresh only what needs to be refreshed and not the whole page.

To redirect to another page, using the HTTP response status code 301 ‘Moved Permanently’ and 302 ‘Found’ is a better option.

<head>
<meta http-equiv="refresh" content="5">   <!-- Non-Compliant -->
<meta name="description" content="..."> 
</head>

Image, area and button with image elements should have an alt attribute

The `alt attribute provides a textual alternative to an image.

It is used whenever the actual image cannot be rendered.

Common reasons for that include:

The image can no longer be found
Visually impaired users using a screen reader software
Image loading is disabled, to reduce data consumption on mobile phones

It is also very important not to set an alt attribute to a non-informative value. For example, <img … alt=“logo”> is useless as it doesn’t give any information to the user. In this case, as for any other decorative image, it is better to use a CSS background image instead of an <img> tag. If using CSS background-image is not possible, an empty alt="" is tolerated. See Exceptions below.

This rule raises an issue when:

An <input type=“image”> or <area> element has no alt attribute or it holds an empty string value.
An <img> element has no alt` attribute.

<li *ngFor="let image of images">
<img [src]="image" alt="">
</li>

JSP expressions should not be used

JSP expressions (using <%= … %>) have been deprecated because they:

Are not unit testable.
Are not reusable.
Cannot make use of object oriented concepts such as inheritence.
Have poor error handling capabilities: if an exception is thrown, an empty page is rended.
Mix the business and presentation logic.

JSP Standard Tag Library (JSTL) and Expression Language should be used instead, enabiling the adoption of the model-view-controller (MVC) design pattern which reduces the coupling between the presentation tier and the business logic.

<input type="text" name="foo" value="<%= request.getParameter("foo") %>" />

Some Java packages or classes should not be used in JSP files

This rule raises an issue when a configured Java package or class is used in a JSP file.

<%@ page import="java.sql.*" %>     <!-- Noncompliant -->
<% java.util.ArrayList clients; %>  <!-- Noncompliant -->
<% java.lang.String name; %>        <!-- Compliant -->

Track uses of disallowed attributes

All HTML tags should be closed

Even if all browsers are fault-tolerant, HTML tags should be closed to prevent any unexpected behavior.

<html>
<head>
<title>Test Page    <!-- Noncompliant; title not closed -->
<!-- Noncompliant; head not closed -->
<body>
<em>Emphasized Text  <!-- Noncompliant; em not closed -->
<!-- Noncompliant; body not closed -->
</html>

HTML <table> should not be used for layout purposes

HTML <table> elements should not be used for layout purpose as it can confuse screen readers. It is recommended to use CSS instead.

This rule raises an issue on every <table> element containing a role attribute set to “presentation” or “none”, which is how W3C recommends marks layout tables.

<table role="presentation">
<!-- ... -->
</table>

Server-side image maps (ismap attribute) should not be used

The `ismap attribute in an img tag creates a server-side image map: The browser sends the coordinates of the clicked point to the server.

For any person who cannot use a mouse, this form of navigation is inaccessible because it is the position of the cursor on the image that determines the action.

On the other hand, client-side image maps, which use the usemap` attribute allow for each clickable area to specify an alternate text, enabling accessibility for the blind.

Further, in terms of separation of concerns, it is definitely better to leave the task of mapping pixels to links to the client.

<a href="click_on_world_map.php" target="_self">
<img src="world_map.png" ismap>              <!-- Noncompliant -->
</a>

Tables should have headers

Table headers are essential to enhance the accessibility of a table’s data, particularly for assistive technologies like screen readers. These headers provide the necessary context to transform data into information. Without headers, users get rapidly lost in the flow of data.

This rule raises an issue whenever a <table> does not contain any <th> elements.

<table role="presentation">
<tr>
<td>Name</td>
<td>Age</td>
</tr>
<tr>
<td>John Doe</td>
<td>42</td>
</tr>
</table>

Links should not directly target images

Whenever a user clicks on a link that targets an image, the website’s navigation menu will be lost.

From a user point of view, it is as if she left the website.

The only way to return to it is using the browser’s ‘Back’ button.

Instead, it is better to create a page which will display the image using the `<img> tag and preserve the navigation menu.

Further, in terms of accessibility, when the image is embedded into a page, content providers are able to provide an alternate text equivalent through the alt` attribute.

<a href="image.png">...</a>  <!-- Non-Compliant -->

input, select and textarea tags should be labeled

The `<label> tag defines a label for <input>, <select> and <textarea> elements.

The <label> tag improves usability for visually impaired users: Screen readers will announce the label text whenever the focus is set on the input field.

It also improves usability for users with impaired motor control: when the text within the <label> element is clicked, the associated input field is toggled.

In most cases, for attribute of the <label> tag should be equal to the id attribute of the related element to bind them together.

Sometimes the field is explained by an icon. In this case the label can be either hidden or the <input>, <select> or <textarea> tags should contain one of the following attributes: aria-label, aria-labelledby. Screen-readers will use those attributes to describe the field.

The purpose of this rule is to make sure that every input (except submit, button, image, and hidden inputs), select, and textarea` field has a label.

<input type="text" name="firstname" />               <!-- Non-Compliant - no id -->

<input type="text" name="lastname" id="lastname" />  <!-- Non-Compliant - no matching label for "lastname" -->

<label for="address">Address</label>
<input type="text" name="address" id="address" />    <!-- Compliant -->

<input type="hidden" name="time" value="...">        <!-- Compliant - "hidden" type is excluded -->
<input type="submit" value="Send" />                 <!-- Compliant - "submit" type is excluded -->

The style attribute should not be used

The goal of this rule is to ban the usage of HTML “style” property to make sure that all CSS styles are defined in CSS classes. Consolidating all styling into classes makes it easier to read, understand and maintain.

<body>
<h1 style="color: blue;">Hello World!</h1>  <!-- Noncompliant -->

Track uses of disallowed namespaces in XHTML documents

This rule allows to ban declaration of some namespaces in the root element of XHML documents.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"    <!-- Noncompliant -->
    xmlns:h="http://java.sun.com/jsf/html"  
    xmlns:f="http://java.sun.com/jsf/core">

<frames> should have a title attribute

Frames allow different web pages to be put together on the same visual space. Users without disabilities can easily scan the contents of all frames at once. However, visually impaired users using screen readers hear the page content linearly.

The title attribute is used to list all the page’s frames, enabling those users to easily navigate among them. Therefore, the <frame> and <iframe> tags should always have a title attribute.

<frame src="index.php?p=menu">                                      <-- Non-Compliant -->
<frame src="index.php?p=home" name="contents">                      <-- Non-Compliant -->

<fieldset> tags should contain a <legend>

For users of assistive technology such as screen readers, it may be challenging to know what is expected in each form’s input. The input’s label alone might not be sufficient: ‘street’ could be part of a billing or a shipping address for instance.

Fieldset legends are read out loud by screen readers before the label each time the focus is set on an input. For example, a legend ‘Billing address’ with a label ‘Street’ will read ‘Billing address street’. Legends should be short, and ‘Your’ should not be repeated in both the legend and the label, as it would result in ‘Your address Your City’ being read.

<fieldset>                                 <!-- Noncompliant -->
Street: <input type="text"><br />
Town: <input type="text"><br />
Country: <input type="text"><br />
</fieldset>

Assistive technologies, such as screen readers, will not be able to render `<object> elements, in such cases it is the content of the <object> which is provided to the user. This alternative content needs to be accessible or the screen readers won’t be able to use it. For example, if an <img> is used it must contain an alt attribute (see corresponding rule Web:ImgWithoutAltCheck).

This rule raises an issue when an <object>` tag does not have any alternative content.

<object></object> <!-- Noncompliant -->

<object>
<object></object> <!-- Noncompliant -->
</object>

aria-label or aria-labelledby attributes should be used to differentiate similar elements

If a page contains multiple `<nav> or <aside> elements, each one should have an aria-label or aria-labelledby attribute so that they can be differentiated. The same rule applies when multiple elements have a role attribute with the same “landmark” value.

Landmark roles are: banner, complementary, contentinfo, form, main, navigation, search, application`.

The use of ARIA markup helps users of screen readers navigate across blocks of content. For example it makes groups of links easier to locate or skip.

<nav> <!-- Noncompliant -->
<ul>
    <li>A list of navigation links</li>
</ul>
</nav>

<article>
<nav> <!-- Noncompliant -->
    Another list of navigation links
</nav>
</article>

Locale should be specified for String case conversion

Failure to specify a locale for String case conversions means the system default encoding will be used, possibly creating problems with international characters. Such code may work fine in its “home” environment, but break in ways that are extremely difficult to diagnose for customers who use different encodings. Such bugs can be nearly, if not completely, impossible to reproduce when it’s time to fix them.

String myStr = "José is a nice guy.";
String myUcString = myStr.toUpperCase(); // Noncompliant

Videos should have subtitles

In order to make your site usable by as many people as possible, subtitles should be provided for videos.

This rule raises an issue when a `video does not include at least one <track/> tag with the kind attribute set to captions, or descriptions or at the very least subtitles.

Note that the subtitles kind is not meant for accessibility but for translation. The kind captions targets people with hearing impairment, whereas descriptions` targets people with vision impairment.

<video id="video" controls preload="metadata">
<source src="resources/myvideo.mp4" type="video/mp4">
<source src="resources/myvideo.webm" type="video/webm">
</video>

Dynamic includes should not be used

Content that doesn’t change or that doesn’t change often should be included using a mechanism which won’t try to interpret it. Specifically, <%@ include file=”…” %>, which includes the file in the JSP servlet translation phase (i.e. it happens once), should be used instead of <jsp:include page=”…” />, which includes the page on the file, when the content is being served to the user.

<jsp:include page="header.jsp">  <!-- Noncompliant -->

HTML comments should be removed

ts in a page that will be generated or interpolated server-side before being served to the user increases the risk of exposing data that should be kept private. For instance, a developer comment or line of debugging information that’s left in a page could easily (and has) inadvertently expose:

Version numbers and host names
Full, server-side path names
Sensitive user data

Every other language has its own native comment format, thus there is no justification for using HTML-style comments in anything other than a pure HTML or XML file.

<%-- Replace 'world' with name --%>  // Compliant
  <h2>Hello world!</h2>

Labels should be defined in the resource bundle

Web applications can be made available in multiple languages through the use of internationalization. This allows the server to plug in the correct version of a piece of text based on the language chosen, but it requires that internationalization messages be used instead of hard-coded text.

<form method="post">
<label for="username">Username:</label>  <!-- Noncompliant -->
<input type="text" id="username" name="username">

<label for="password">Password:</label>  <!-- Noncompliant -->
<input type="password" id="password" name="password">

<input type="submit" name="submit" value="${buttonValue}">
</form>

Links with identical texts should have identical targets

When links with different targets are given identical link text, this can produce confusion for users of assistive technologies, some of which provide users the ability to view a list of all links on the page.

When this list of links is presented to the user they may be left not knowing the links go to different destinations.

Even if they do realize the links go to different destinations, they may be left not knowing which link to follow to go to the destination they desire.

<a href="a.html">qux</a>
<a href="b.html">qux</a>          <!-- Noncompliant; same text, different targets -->

<a href="c.html">foo</a>
<a href="d.html">foo</a>          <!-- Noncompliant; same text, different targets -->

Favicons should be used in all pages

Favicons are shown for example in the browser’s address bar, bookmark list, or tabs.

They enable users to quickly identify and recognize websites.

<head>                                                                  <!-- Noncompliant -->
<title>...<title>
</head>

Mouse events should have corresponding keyboard events

Offering the same experience with the mouse and the keyboard allow users to pick their preferred devices.

Additionally, users of assistive technology will also be able to browse the site even if they cannot use the mouse.

This rule raises an issue when:

an HTML element with an `onMouseover attribute doesn’t also have an onFocus attribute.
an HTML element with an onMouseout attribute doesn’t also have an onBlur attribute.
an HTML element with an onClick attribute doesn’t also have one of the following attributes: onKeyDown, onKeyUp, onKeyPress.

Note that in the case of onClick`, the equivalent keyboard handler should support both the “Enter” and “Space” keys as these are usually used by screen-readers.

<div onClick="doSomething();" ...>                                <!-- Noncompliant - 'onKeyDown/onKeyUp/onKeyPress' missing -->
<a onMouseover="doSomething();" ...>                            <!-- Noncompliant - 'onFocus' missing -->
<a onMouseout="doSomething();" ...>                             <!-- Noncompliant - 'onBlur' missing -->

Unescaped JSON data should not be written to the output

In cross-site scripting attacks, attackers insert attack scripts into your pages. Because no system is fool-proof, it may not be enough to screen the data that’s submitted to an application. You should also escape any content sent to the user so that any malicious code that may have escaped your input screening is neutralized. Specifically, the characters crucial to forming HTML (`&, <, >, ”, ’, and /) must be escaped.

This rule checks that values are not written directly into application/json` blocks or JavaScript variables.

<script id="data" type="application/json">
<%= data.json_payload %>  // Noncompliant
<script>

<script>
var initialData = <%= data.json_payload =>;  // Noncompliant
</script>

Unused values should not be calculated

Calculating or retrieving a value only to then overwrite it or throw it away, could indicate a serious error in the code. Even if it’s not an error, it is at best a waste of resources. Therefore all calculated values should be used.

void calculateRate(int a, int b)
{
int i;

i = a + b; // Noncompliant; calculation result not used before value is overwritten
i = doSomething();  // Noncompliant; retrieved value not used
for (i = 0; i < 10; i++) { 
//  ...
}
// ...
}

Multiple page directives should not be used

While you can use as many page directives as you like, it is more readable to set multiple page attributes in a single directive.

The exception to this rule is when multiple packages are being imported. In that case, imports may be done in separate directives and all other attributes should be set in a single, additional directive.

<%@ page session="false" %>
<%@ page import="java.util.*" %>
<%@ page errorPage="error.jsp" %> <!-- Noncompliant -->
<%@ page import="java.text.*" %>

Attributes deprecated in HTML5 should not be used

HTML5 is the fifth and current major version of HTML. HTML5 introduced many new elements, attributes, and behaviors. While HTML5 also aimed to be backward-compatible with common parsing of older versions of HTML, many old attributes were deprecated.

The main reason these attributes were deprecated in HTML5 is to separate the concerns of content structure (HTML) and presentation (CSS). This is a fundamental principle of modern web design known as the separation of concerns, which provides multiple advantages:

Maintainability: By separating content and presentation, you can change the look and feel of a website without touching the HTML. You only need to modify the CSS.
Reusability: CSS styles can be reused across multiple pages, making it easier to keep a consistent look and feel across an entire website.
Accessibility: Using CSS for presentation makes it easier to create websites that are accessible to users with disabilities. For example, screen readers can more easily interpret web content when it’s separated from the presentation.

<table>
<tr>
	<td width="50%">1st cell</td><!-- Noncompliant: 'width' attribute is deprecated -->
	<td width="50%">1st cell</td>
</tr>
</table>

White space should be used in JSP/JSF tags

The proper use of white space makes a major contribution to code readability.

This rule raises an issue when there is not a space character after the beginning and before the end of each comment (<!— … —>), directive (<%@ … %>), and expression (<% … %>).

<!--Do the thing-->  <!-- Noncompliant; missing space at beginning and end of text-->
<%@page import="java.io.*,java.util.*" %> <!-- Noncompliant; missing space at beginning -->
<% String title = "My Page";%> <!-- Noncompliant; missing space at end -->

Authorizing an opened window to access back to the originating window is security-sensitive

A newly opened window having access back to the originating window could allow basic phishing attacks (the window.opener object is not null and thus window.opener.location can be set to a malicious website by the opened page).

For instance, an attacker can put a link (say: “http://example.com/mylink”) on a popular website that changes, when opened, the original page to “http://example.com/fake_login”. On “http://example.com/fake_login” there is a fake login page which could trick real users to enter their credentials.

<a href="http://example.com/dangerous" target="_blank"> <!-- Sensitive -->

<a href="{{variable}}" target="_blank"> <!-- Sensitive -->

Track lack of copyright and license headers

Each source file should start with a header stating file ownership and the license which must be used to distribute the application.

This rule must be fed with the header text that is expected at the beginning of every file.

<html>                                    <!-- Noncompliant -->
...
</html>

Track uses of TODO tags

Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

<html>
<!-- TODO support small device -->
...
</html>

Using remote artifacts without integrity checks is security-sensitive

Using remote artifacts without integrity checks can lead to the unexpected execution of malicious code in the application.

On the client side, where front-end code is executed, malicious code could:

impersonate users’ identities and take advantage of their privileges on the application.
add quiet malware that monitors users’ session and capture sensitive secrets.
gain access to sensitive clients’ personal data.
deface, or otherwise affect the general availability of the application.
mine cryptocurrencies in the background.

Likewise, a compromised software piece that would be deployed on a server-side application could badly affect the application’s security. For example, server-side malware could:

access and modify sensitive technical and business data.
elevate its privileges on the underlying operating system.
Use the compromised application as a pivot to attack the local network.

By ensuring that a remote artifact is exactly what it is supposed to be before using it, the application is protected from unexpected changes applied to it before it is downloaded. Especially, integrity checks will allow for identifying an artifact replaced by malware on the publication website or that was legitimately changed by its author, in a more benign scenario.

Important note: downloading an artifact over HTTPS only protects it while in transit from one host to another. It provides authenticity and integrity checks for the network stream only. It does not ensure the authenticity or security of the artifact itself.

<script
src="https://cdn.example.com/latest/script.js"
></script> <!-- Sensitive -->

Get Started