Change <ol> to <ul> when no order is intended (non-normative)

[patrickhlauke]

The understanding documents are oddly inconsistent when it comes to use of <ol> and <ul>. This edits all cases (particularly in the newer 2.2 understanding docs, but some older ones too) where a list does not have an explicit order and should just be an unordered list

---

Preview | Diff

[bruce-usab]

Briefly discuss on call 3/22/2024, and we determined needed closer review.

@patrickhlauke might this be expedited by spitting the non-normative documents into their own PR?

Also, it is sometimes helpful to have LI numbered if only because that makes them easier to reference in a conversation. Is that enough justification to assert that order matters?

[patrickhlauke]

I guess I could split this PR into two for the changes in the guidelines folder (normative) and the ones in the conformance-challenges and understanding (informative)

I admit I don't buy the rationale about numbered list items as reference, at least not in the cases that I patch here.

[patrickhlauke]

@bruce-usab I've removed the changes to normative documents (I'm assuming conformance-challenges is non-normative?) which would make this less controversial. Filing the same change to the normative ones as a separate PR

[patrickhlauke]

Done #3756

[bruce-usab]

Thank you @patrickhlauke for splitting off the normative docs. I had hoped to get to this PR on the call today, but I messed up the opportunity for that.

Everything looks good to me, but I think the conformance-challenges file has hard-coded references to 2.1 instead of 2.2. I think that might be addressed in a different PR in the future, or maybe split off the one file to get the other 13 quickly through?

I retract my comment about maybe OL having some utility.

• Some of the LI are sorted by SC numbering, so OL is unhelpful.
• Other places OL is clearly semantically correct, since there is not any apparent order. I can't think of situations where having a number to refer to would matter. The lists are short and it's better to refer to the thing than the number for the thing.

[fstrr]

@patrickhlauke There's a couple of merge conflicts that have appeared. The Conformance Challenges one is straight forward, but the Text Spacing one looks like there's more to it than that and is conflicting with #3572, which was merged into main three days ago. Could you take a look at that one please?

[patrickhlauke]

@fstrr thanks for checking. sigh...

[fstrr]

@patrickhlauke Could be worse…

[patrickhlauke]

@fstrr sorted (the text spacing one was odd ... it was showing a huge chunk being out of sync, but in reality it wasn't)

[fstrr]

@patrickhlauke Oh, that's good.

[patrickhlauke]

@fstrr want me to have a look at the mega-conflicts in the other one? I suspect it's something small, like a space before a closing /, but in lots of files, and in a way that confuses github's merge capability...

[fstrr]

@patrickhlauke If you want to, that would be super helpful. It looks like your "chore: update HTML files for xslt/xml processing" update is the issue with the 66 files, so, yeah, it's probably something really straightforward. Thanks :)

[bruce-usab]

I have reviewed changes since I last reviewed, and I have no concerns.

[alastc]

@patrickhlauke to check that, once built, the techniques still come out (e.g. for focus-not-obscured-min).

The XSLT may forget to output them if it's not expecting <ul>s.

[bruce-usab]

This PR includes the one source file for Challenges with Accessibility Guidelines Conformance and Testing, and Approaches for Mitigating Them. I think that is fine, since (1) it is an AG WG document, which (2) is a working draft, and (3) this is editorial. Per the discussion on the call 4/12, @mbgower this detail might be worth flagging when sent for WG review.