Accessibility in Task Lists: Level AA 1.3.5 Identify Input Purpose

[SallyMcGrath]

My journey of discovery brings me to you.

I am using goldmark in Hugo to display a small front end for our course and while I was testing I noticed that task lists as rendered by markdown are hitting my scores in Lighthouse. This is because the form elements do not have associated labels. The purpose of the input is not identified.

Lighthouse admonition
Relevant WCAG entry 1.3.5 Identify Input Purpose

I come to you because:

1. I read the CommonMark spec and there are no task lists
2. I read the Goldmark repo and they require "You should confirm your output is different from other official renderers correspond with an extension"
3. I read your spec and here there are task lists. I can see you clearly state that "This spec does not define how the checkbox elements are interacted with" however Goldmark output is identical to yours in this case:

https://github.com/CodeYourFuture/immersive-go-course/blob/main/website/content/workbooks/workbook-0.md
https://cyf-systems.netlify.app/workbooks/workbook-0/ (not "launched" yet)

It seems clear that it's undesirable to remove the inputs from the Accessibilty API with aria-hidden or presentation role as checkboxes have powers on GitHub. Would it be possible to wrap the inner text of li and input with a label and use implicit association? I guess there's a reason it isn't like this already, though. (I did search issues but couldn't find anything. )

I definitely don't have enough context on GFM task lists, but you all do, so I bring you this problem and ask for your help.

Thank you for GFM! It's really really useful and brilliant.

[wooorm]

@anticomputer PR does not seem to match this issue?

[wooorm]

@anticomputer Ping!

[anticomputer]

@anticomputer PR does not seem to match this issue?

Thanks for the heads up, the reference to #299 was from an upstream commit in cmark, which got confused for this one out of the upstream commit message.