Is it possible to see whole failing element path inside HTML report?

[zunjooo]

Expected behaviour

It would be more helpful to see whole failing element path inside report after test.

Actual behaviour

I just see part of element's path, for example: <fieldset> <!-- search-redirect.php is pr...</fieldset>

I am talking about part with "..." after some part of element.

Steps to reproduce

0. Install html reporter npm install pa11y-reporter-html

1. Start test with wikipedia page for example like: pa11y --reporter html http://wikipedia.com

2. Output body of html file looks like this: `

    <h1>Accessibility Report For "http://www.wikipedia.com/"</h1>
    <p>Generated at: Tue Mar 12 2019 10:23:24 GMT+0000 (Coordinated Universal Time)</p>
   
    <p class="counts">
    	<span class="count error">3 errors</span>
    	<span class="count warning">0 warnings</span>
    	<span class="count notice">0 notices</span>
    </p>
   
    <ul class="clean-list results-list">
    	<li class="result error">
    		<h2>Error: Anchor element found with a valid href attribute, but no link content has been supplied.</h2>
    		<p>WCAG2A.Principle4.Guideline4_1.4_1_2.H91.A.NoContent</p>
    		<pre>&lt;a href=&quot;http://www.wikipedia.com&quot;&gt;
                &lt;svg class...&lt;/a&gt; (select with "html &gt; body &gt; div:nth-child(1) &gt; div &gt; div:nth-child(1) &gt; div &gt; div &gt; div:nth-child(2) &gt; a")</pre>
    	</li>
    	<li class="result error">
    		<h2>Error: Anchor element found with a valid href attribute, but no link content has been supplied.</h2>
    		<p>WCAG2A.Principle4.Guideline4_1.4_1_2.H91.A.NoContent</p>
    		<pre>&lt;a href=&quot;http://www.wikipedia.com&quot;&gt;
                &lt;svg class...&lt;/a&gt; (select with "html &gt; body &gt; div:nth-child(1) &gt; div &gt; div:nth-child(2) &gt; div &gt; div &gt; div:nth-child(2) &gt; a")</pre>
    	</li>
    	<li class="result error">
    		<h2>Error: Anchor element found with a valid href attribute, but no link content has been supplied.</h2>
    		<p>WCAG2A.Principle4.Guideline4_1.4_1_2.H91.A.NoContent</p>
    		<pre>&lt;a href=&quot;https://www.wikipedia.com&quot;&gt;
                &lt;svg class...&lt;/a&gt; (select with "html &gt; body &gt; footer &gt; div:nth-child(2) &gt; div:nth-child(3) &gt; div:nth-child(2) &gt; a")</pre>
    	</li>
    </ul>
   

`

3. Is it possible to see whole path for for example this element? <a href="http://wikipedia.com"> <svg class...</a> (select with "html > body > div:nth-child(1) > div > div:nth-child(1) > div > div > div:nth-child(2) > a")

I am talking about part after <svg class...

Environment:

Pa11y: 5.1.0 Node.js: 10.1.0 npm: 6.4.1 OS: 18.2.0 (darwin)

[krukru]

This issue is related to this snippet https://github.com/pa11y/pa11y/blob/ddcbb3696a43f775e32399bbafeea7f12c9d6cbb/lib/runner.js#L121-L136

For some reason, long html elements get truncated, which makes finding (and fixing) them very difficult. Can you give some context to this rule, we would be happy to make a PR if you think this truncating is no longer needed.

[krukru]

We failed to notice that pa11y reporter also gives a css selector, which helps to pinpoint exactly the element in question :)

[joeyciechanowicz]

Maybe @hollsk might remember? The only reason I can think of is to keep reports a bit more concise.

Otherwise I can't see a reason that the outerHTML has to be truncated still.

[hollsk]

No idea, I'm afraid. @rowanmanning ?

[rowanmanning]

Yep, this is because the element's outerHTML and innerHTML are potentially very large, just attributes alone on certain elements are huge (think storing JSON in a data- attribute) and sending them between PhantomJS and the Node.js process would time out for many pages back in the day.

Since this we've switched to Chrome/Puppeteer, which may not present the same issue, however it would still be easy to get out-of-memory errors in Node.js when each of the error objects has an enormous string to describe the exact element's HTML.

This might be acceptable in the Pa11y command-line tool, but it would present a risk for anyone running the webservice and dashboard – you don't want the structure of an HTML page to be able to crash your webservice.

One solution may be to increase the max size of the truncation?

[joeyciechanowicz]

One solution may be to increase the max size of the truncation?

That sounds like a sane idea. Something large enough to generally always print out the whole outerHHTML, but not stop things working. Perhaps ~1024 for the outerHTML.

Is there a need for a long innerHTML?

[rowanmanning]

Or another potential solution (though it's complicated): we get the element's tagName, loop over its attributes and construct the outerHTML ourselves using those. If an individual attribute name or value is longer than we allow then we concat just that attribute, and if the whole thing is longer than ~1024 then we also concat that. We could even prioritise identifying information, e.g. the id attribute, putting that first.

Pros:

• Keeps the output short
• Prioritises identifying information, possibly making it easier to find elements

Cons:

• More code to maintain
• Possibly makes it harder to find elements if people want to search their code for the full snippet

[joeyciechanowicz]

I knocked out some code to see what it would look like: https://jsfiddle.net/jz1tLp2d/

Whilest writing it I realised some other edge cases such as attributes with no values, which will clutter up the code a bit more.

I think that simply truncating at >1024 characters is sufficient for most cases. When someone has blobs of JSON in attributes, or a huge number of attributes, then the information within that 1024 characters should allow them to locate the element. And when not, there is the CSS selector to fall back on.