Hello Kily22 and welcome to WebmasterWorld [webmasterworld.com]

That "/nu" version of the HTML Validator that you have linked to is not the standard version, it is an experimental version so it is possible that you may find better information from their standard validator tool: [validator.w3.org...] which does offer a specific list of issues and fixes.

Keep in mind that WordPress is not quite the same as a site built only with HTML which is what that w3.org tool is intended to validate.

Note that a number of the errors shown are due to the use of schema tags (that is the "structured-data" lines) which should be tested using schema testing tools and ignored in HTML validation.

Various WP themes and plugins may use scripts that can show as errors but are fully functional. Also keep in mind that your report does not require you to "fix" all warnings and errors. They are given to you so you can decide what you need or want to correct or change. It is entirely possible to have valid HTML that cannot be validated due to extraneous lines from scripts that do not affect the performance but do prevent validation.

Keep in mind that WordPress is not quite the same as a site built only with HTML which is what that w3.org tool is intended to validate.

But is it too much to expect a major CMS to generate valid HTML?

Unfortunately the w3 validator hasn't learned to ignore the various kinds of schema markup, so you'll have to do your own ignoring. Admittedly this is easier when you wrote the HTML yourself, so you know which parts are schema extras.

It does do that lucy24, but then people add plugins and those often add in extra bloat and most of it is not part of what the HTML tool was made to validate. A persona needs to view the reports with that in mind and a copy of what you see in the source code that may trigger !errors! and !warnings! in order to sort through the report. Many plugins let people add in their own pieces of html (and css BTW) which is not the fault of WP if it is poorly done. My response was just a reminder to keep some of those things in mind as one is grappling with the report.

Thank you very much for that explanation. I thought it didn't affect the site.
Unfortunately, I have pressure from superiors to remove some errors... like for example this one

Error: Saw " when expecting an attribute name. Probable cause: = missing immediately before.
At line 112, column 2111
14 9.25 22.5z""></path></svg>

where should I look for the correct error file? Is this a css file? I'm looking for a right file with that kind an error in that line, but can't find it.

You would need to look at the source page "At line 112," and see what is there. Keep in mind that if what you find at line 112 is NOT html then the validator's information may not be relevant.

Come to think of it, running the HTML validator on anything that didn’t start out as raw HTML (such as a local file uploaded from your HD) can be confusing, because all errors are identified by line number. That’s fine on a pure-HTML file: just go to line 543 and there you are. But if it’s a file generated by a CMS or php, or even something with SSIs, you then have to pore over the file to figure out where “line 543” actually occurs. They don’t always give enough information to pinpoint it.

As long as we’re here, it’s also worth pointing out that the validator is the minimum standard: it’s like someone being a complete ### and then saying “There’s no law against it!” Calling thirty stylesheets, to take the obvious example, is perfectly permissible ... but that doesn’t mean it’s a good idea.

In my own (limited!) experience, even with the W3C validator, fixing errors listed earlier in the list will make some of the more mysterious. later errors disappear. Can't think of a good example off the top of my head, but I have found that even some "simple" errors can have a cascading effect, creating apparent errors for the validator in the lines of code following. So, fix what you can and you will probably find that the list of remaining errors from a re-validation is reduced more than you might expect.

I know just what you mean. There are times when I would rather see a thousand errors than ten, because then when I find and fix one thing, everything else disappears.

I have not tried that /nu/ experimental version that is producing these results quoted here, so I'm sticking to generic suggestions. I linked to the standard validator but it does not appear that is what is used to generate the errors mentioned here.

In the HTML Validator, click on "More Options",
then tick the button for "Show Source".
The Validator will then list the source it sees,
with its line numbers, when creating the report.
Especially useful with PHP pages.

Ahhhh ... ! There have been times when I wish now that I had known that. </understatement> Thanks, Jonesy.

Regarding the schema markup, you're using the old version of markup. Use JSON-LD because it's what Google prefers AND it won't trigger warnings.

Good luck!
;)

Roger Montti