E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Michael H
Date: Sun, Aug 08 2021 10:00PM
Subject: Nu HTML Checker
No previous message | Next message →

Hello,

As part of an accessibility audit, I am tasked with correcting feedback
from the Nu HTML Checker:

https://validator.w3.org/nu/

The site that I am checking is an Angular-powered single page application.

Almost all of the errors I'm getting look like:

*Error*: Attribute _ngcontent-hdu-c107 not allowed on element span
<https://html.spec.whatwg.org/multipage/#the-span-element> at this point.

It's barking about Angular's automatic attribute generation naming
conventions. *Is this something that is safe for me to ignore?*

Has anyone else here run into this issue? If so, how did you solve it?

Many thanks!

From: Steve Green
Date: Mon, Aug 09 2021 1:56AM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

The short answer is yes, you can ignore those validation errors. The long answer is...

WCAG2.1 SC 4.1.1 only requires you to report certain types of validation error. You should use a bookmarklet to filter the results so you only see the relevant ones. But which bookmarklet should you use?

Some of my team use https://github.com/stevefaulkner/wcagparsing. However, I recently reported an issue whereby I believe it is not filtering out all the validation errors I think it should.

Personally, I use https://dotjay.github.io/wcag-parsing-filter/bookmarklet/. This is based on Steve Faulkner's bookmarklet, but it filters out the validation errors mentioned above.

That said, I raised a couple of queries with regard to the latter more than a year ago, whereby I believe some results are filtered out incorrectly and some are not filtered out when they should be. I have not yet had an answer. Those queries would also apply to Steve Faulkner's bookmarklet.

The bottom line is that there is not a definitively correct filtering algorithm (that I am aware of). Furthermore, all such bookmarklets are fragile because they work by detecting specific strings in the validator's output. If the developers of the validator change even one character in a string, the bookmarklets will stop working correctly to some degree. Worse still, they will fail silently.

Steve Green
Managing Director
Test Partners Ltd

From: Michael H
Date: Mon, Aug 09 2021 1:17PM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

Thank you for all the helpful information Steve, I greatly appreciate it!

We are using Accessibility Insights for Web, and this is one of the
sections that QA flagged. Accessibility Insights for Web gives us the
instructions/bookmarklets for filtering, but it seems very unhelpful to see
what appear to be innocuous errors.

I'm going to go over your links today as I work on this and I will respond
again if I run into any issues or discover anything that might be helpful
to others.

Thanks again for taking the time to provide detailed information! You're a
life saver. :)

From: glen walker
Date: Mon, Aug 09 2021 2:22PM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

A bookmarklet or other filtering tool for the NU results would be nice but
I'm not sure I'd trust the results. As Steve said, it might not fully
filter, and I'd be worried it filtered too much. But I understand there's
a lot of "noise" in the parsing results. Technically, 4.1.1 only lists
four types of parsing errors, but some of the other parsing errors can
point out accessibility issues. For example, parsing can find IDs that
don't exist such as an aria-labelledby pointing to an ID that is misspelled
or incorrectly pointing to the NAME attribute. Those aren't technical WCAG
4.1.1 errors but they are accessibility issues that would hopefully be
caught when you're looking for 4.1.2 issues. A 4.1.1 filtering bookmarklet
might filter those results out since they're not one of the four mentioned
in the SC but I wouldn't want those filtered out.

I find that a manual inspection of the results works best (for me). I use
the "message filtering" option of the NU results which helps to group items
together and makes it much easier to go through.

But I'm digressing from the original question about NG attributes and agree
with Steve that they can be ignored.

From: Michael H
Date: Mon, Aug 09 2021 2:46PM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

Thank you for the help Glen!

You folks are awesome!

I will do a manual inspection. "Message filtering" is a much better view to
look at.

Thanks again to you and Steve. I will be forwarding this thread to my QA
member for them to reference as well.

I'll be back if I have more questions. Much appreciated!



On Mon, Aug 9, 2021 at 1:22 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> A bookmarklet or other filtering tool for the NU results would be nice but
> I'm not sure I'd trust the results. As Steve said, it might not fully
> filter, and I'd be worried it filtered too much. But I understand there's
> a lot of "noise" in the parsing results. Technically, 4.1.1 only lists
> four types of parsing errors, but some of the other parsing errors can
> point out accessibility issues. For example, parsing can find IDs that
> don't exist such as an aria-labelledby pointing to an ID that is misspelled
> or incorrectly pointing to the NAME attribute. Those aren't technical WCAG
> 4.1.1 errors but they are accessibility issues that would hopefully be
> caught when you're looking for 4.1.2 issues. A 4.1.1 filtering bookmarklet
> might filter those results out since they're not one of the four mentioned
> in the SC but I wouldn't want those filtered out.
>
> I find that a manual inspection of the results works best (for me). I use
> the "message filtering" option of the NU results which helps to group items
> together and makes it much easier to go through.
>
> But I'm digressing from the original question about NG attributes and agree
> with Steve that they can be ignored.
> > > > >

From: Birkir R. Gunnarsson
Date: Tue, Aug 10 2021 5:00AM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

The NG attributes come with Angular, nothing we can do about them. If
Angular really wanted to adhere to HTML, those should start with
"data-" but coding frameworks are sadly notoriously bad about
producing semantically valid//accurate HTML.
Fortunately, in this case, these attributes are harmless, as our
fellow listers have already pointed out.


On 8/9/21, Michael H < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you for the help Glen!
>
> You folks are awesome!
>
> I will do a manual inspection. "Message filtering" is a much better view to
> look at.
>
> Thanks again to you and Steve. I will be forwarding this thread to my QA
> member for them to reference as well.
>
> I'll be back if I have more questions. Much appreciated!
>
>
>
> On Mon, Aug 9, 2021 at 1:22 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
>> A bookmarklet or other filtering tool for the NU results would be nice but
>> I'm not sure I'd trust the results. As Steve said, it might not fully
>> filter, and I'd be worried it filtered too much. But I understand there's
>> a lot of "noise" in the parsing results. Technically, 4.1.1 only lists
>> four types of parsing errors, but some of the other parsing errors can
>> point out accessibility issues. For example, parsing can find IDs that
>> don't exist such as an aria-labelledby pointing to an ID that is
>> misspelled
>> or incorrectly pointing to the NAME attribute. Those aren't technical
>> WCAG
>> 4.1.1 errors but they are accessibility issues that would hopefully be
>> caught when you're looking for 4.1.2 issues. A 4.1.1 filtering
>> bookmarklet
>> might filter those results out since they're not one of the four mentioned
>> in the SC but I wouldn't want those filtered out.
>>
>> I find that a manual inspection of the results works best (for me). I use
>> the "message filtering" option of the NU results which helps to group
>> items
>> together and makes it much easier to go through.
>>
>> But I'm digressing from the original question about NG attributes and
>> agree
>> with Steve that they can be ignored.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Max ability
Date: Tue, Aug 10 2021 7:22AM
Subject: Re: Nu HTML Checker
← Previous message | Next message →

The reason anyone use the HTML markup validation service for accessibility
testing is to test for 4.1.1 parsing. One set of a11y professionals say the
4 tests
a. Finding duplicate attributes for elements
b. Finding duplicate Id values
c. Improper opening and closing of elements
d. Nesting according to specifications.

These 4 items can be easily identified with other tests the consultants.
Eg: Screen readers testing can identify the improper opening and closing of
elements and some parts of nesting of elements.
Automation tools can identify duplication of id values and improper
structure of elements as per specifications etc.
May be you may want to run some samples to see how much worth it brings in
performing HTML validation just to find parsing issues.
Regards
Rakesh

On Tue, Aug 10, 2021 at 4:30 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> The NG attributes come with Angular, nothing we can do about them. If
> Angular really wanted to adhere to HTML, those should start with
> "data-" but coding frameworks are sadly notoriously bad about
> producing semantically valid//accurate HTML.
> Fortunately, in this case, these attributes are harmless, as our
> fellow listers have already pointed out.
>
>
> On 8/9/21, Michael H < = EMAIL ADDRESS REMOVED = > wrote:
> > Thank you for the help Glen!
> >
> > You folks are awesome!
> >
> > I will do a manual inspection. "Message filtering" is a much better view
> to
> > look at.
> >
> > Thanks again to you and Steve. I will be forwarding this thread to my QA
> > member for them to reference as well.
> >
> > I'll be back if I have more questions. Much appreciated!
> >
> >
> >
> > On Mon, Aug 9, 2021 at 1:22 PM glen walker < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> A bookmarklet or other filtering tool for the NU results would be nice
> but
> >> I'm not sure I'd trust the results. As Steve said, it might not fully
> >> filter, and I'd be worried it filtered too much. But I understand
> there's
> >> a lot of "noise" in the parsing results. Technically, 4.1.1 only lists
> >> four types of parsing errors, but some of the other parsing errors can
> >> point out accessibility issues. For example, parsing can find IDs that
> >> don't exist such as an aria-labelledby pointing to an ID that is
> >> misspelled
> >> or incorrectly pointing to the NAME attribute. Those aren't technical
> >> WCAG
> >> 4.1.1 errors but they are accessibility issues that would hopefully be
> >> caught when you're looking for 4.1.2 issues. A 4.1.1 filtering
> >> bookmarklet
> >> might filter those results out since they're not one of the four
> mentioned
> >> in the SC but I wouldn't want those filtered out.
> >>
> >> I find that a manual inspection of the results works best (for me). I
> use
> >> the "message filtering" option of the NU results which helps to group
> >> items
> >> together and makes it much easier to go through.
> >>
> >> But I'm digressing from the original question about NG attributes and
> >> agree
> >> with Steve that they can be ignored.
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Michael H
Date: Tue, Aug 10 2021 11:15AM
Subject: Re: Nu HTML Checker
← Previous message | No next message

Thank you Birkir and Max! All of this feedback and advice is extremely
helpful!

I plan on looking over the HTML validation results today to see if there's
anything we may have missed via the numerous other a11y tests. My gut tells
me there's maybe one or two things I'll be able to easily fix across-site,
and then ignore the rest.

I'll post back an update.

Thanks again to everyone for the help!

On Tue, Aug 10, 2021 at 6:22 AM Max ability < = EMAIL ADDRESS REMOVED = >
wrote:

> The reason anyone use the HTML markup validation service for accessibility
> testing is to test for 4.1.1 parsing. One set of a11y professionals say the
> 4 tests
> a. Finding duplicate attributes for elements
> b. Finding duplicate Id values
> c. Improper opening and closing of elements
> d. Nesting according to specifications.
>
> These 4 items can be easily identified with other tests the consultants.
> Eg: Screen readers testing can identify the improper opening and closing of
> elements and some parts of nesting of elements.
> Automation tools can identify duplication of id values and improper
> structure of elements as per specifications etc.
> May be you may want to run some samples to see how much worth it brings in
> performing HTML validation just to find parsing issues.
> Regards
> Rakesh
>
> On Tue, Aug 10, 2021 at 4:30 PM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > The NG attributes come with Angular, nothing we can do about them. If
> > Angular really wanted to adhere to HTML, those should start with
> > "data-" but coding frameworks are sadly notoriously bad about
> > producing semantically valid//accurate HTML.
> > Fortunately, in this case, these attributes are harmless, as our
> > fellow listers have already pointed out.
> >
> >
> > On 8/9/21, Michael H < = EMAIL ADDRESS REMOVED = > wrote:
> > > Thank you for the help Glen!
> > >
> > > You folks are awesome!
> > >
> > > I will do a manual inspection. "Message filtering" is a much better
> view
> > to
> > > look at.
> > >
> > > Thanks again to you and Steve. I will be forwarding this thread to my
> QA
> > > member for them to reference as well.
> > >
> > > I'll be back if I have more questions. Much appreciated!
> > >
> > >
> > >
> > > On Mon, Aug 9, 2021 at 1:22 PM glen walker < = EMAIL ADDRESS REMOVED = >
> > wrote:
> > >
> > >> A bookmarklet or other filtering tool for the NU results would be nice
> > but
> > >> I'm not sure I'd trust the results. As Steve said, it might not fully
> > >> filter, and I'd be worried it filtered too much. But I understand
> > there's
> > >> a lot of "noise" in the parsing results. Technically, 4.1.1 only
> lists
> > >> four types of parsing errors, but some of the other parsing errors can
> > >> point out accessibility issues. For example, parsing can find IDs
> that
> > >> don't exist such as an aria-labelledby pointing to an ID that is
> > >> misspelled
> > >> or incorrectly pointing to the NAME attribute. Those aren't technical
> > >> WCAG
> > >> 4.1.1 errors but they are accessibility issues that would hopefully be
> > >> caught when you're looking for 4.1.2 issues. A 4.1.1 filtering
> > >> bookmarklet
> > >> might filter those results out since they're not one of the four
> > mentioned
> > >> in the SC but I wouldn't want those filtered out.
> > >>
> > >> I find that a manual inspection of the results works best (for me). I
> > use
> > >> the "message filtering" option of the NU results which helps to group
> > >> items
> > >> together and makes it much easier to go through.
> > >>
> > >> But I'm digressing from the original question about NG attributes and
> > >> agree
> > >> with Steve that they can be ignored.
> > >> > > >> > > >> > > >> > > >>
> > > > > > > > > > > > > > >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > > > > >
> > > > >