Ok, Reviewing the original code and the updated code, I se an issue which we didn't really address. In both cases we never did say what this EPUB has been checked against, only if it met the min, met the expected or exceeded.

We don't say if it met WCAG 2.0 2.1 or 2.2. Which is a problem since some folks will require WCAG 2.1 AA, where others might require WCAG 2.2 AA. We also don't point out if this EPUB passed EPUB 1.1 or 1.0. Not sure if that is as big a deal as the WCAG version or not.

@GeorgeKerscher @gregoriopellegrino what do you all think? Or do we need to discuss this at our next editors call?

We have this in:
Permalink for Section 4.3.2
The following information can be placed in a section that shows the details of the conformance information.
Conformance Statement
Identifies the accessibility specification and the conformance level to which the publication assertions are made. When the publication claims to conform to more than one specification, additional conformance statements may be provided.
Certification date
If the date of the certifier's evaluation is provided, then this would be of interest. This is normally associated with the certifier.
Certifier's Report
If a link to a report is provided, this may be of interest.

Perhaps we should use the word must or strongly advise.

we never did say what this EPUB has been checked against, only if it met the min, met the expected or exceeded. We don't say if it met WCAG 2.0 2.1 or 2.2.

What version and level it meets comes after those generic statements based on the level it passed. They come after the detailed conformance information heading is inserted; I have "display conformance_str" in the new code where it's inserted.

What we learned with publication manifest is that when making algorithms it's really helpful to write some public code to implement the instructions. That way anyone can run some samples through and see what results. I can maybe try and adapt the generator I made to implement the current logic.

Wow! That would be outstanding!

I made a few changes in the last commit based on implementing this code:

• I renamed conformance_str to conformance_string to be consistent with naming elsewhere
• I created a variable called conformance and use the language for the certifier info to extract the node rather than test that it is present. This makes it simpler to understand the replace functions that extract the statement and wcag level
• I reorganized the instructions so that there isn't the need for that halting statement in the middle. If conformance_string is empty, then you can bail out right away. The processing now happens in the ELSE that follows.

I also added the missing quotes to the 1.0 xpaths and deleted the extra backet in the certifier xpath so this will also close #511 and #512

The one thing that make me unsure about merging this yet is the string that results from extracting the 1.1 conformance statement and using a regex to delete the hyphen from it.

The result is that we can't associate a single ID with it. It could be any of the nine strings. Should we list all of these with their IDs or put them in a note? It makes localization a little more complicated as you have to translate the English text to an ID before you can match the localization. It's not like the other instructions that end in an single ID value.