mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-11-23 21:02:09 +00:00
Compare commits
2 commits
dadfd94963
...
dba55eba92
Author | SHA1 | Date | |
---|---|---|---|
|
dba55eba92 | ||
|
7ee5215e5e |
2 changed files with 29 additions and 0 deletions
12
content/notes/hugo-microformats.md
Normal file
12
content/notes/hugo-microformats.md
Normal file
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: "Hugo microformats"
|
||||
date: 2022-07-20T11:17:11-07:00
|
||||
replyURI: "https://github.com/gohugoio/hugo/issues/10108"
|
||||
replyTitle: "Support h-feed h-entry (Hugo issue 10108)"
|
||||
replyType: "DiscussionForumPosting"
|
||||
replyAuthor: "Schimon Jehuda"
|
||||
replyAuthorURI: "https://github.com/sjehuda"
|
||||
---
|
||||
I think `h-feed` and `h-entry` should be implemented manually by Hugo theme and/or site authors. Microformats add class names to a page, but someone still has to design a page. There's way more diversity in h-feed design than RSS, Atom, or JSON-feed design because h-feeds are webpages meant for humans first, machines second. Providing built-in h-feed templates would be akin to providing a default incomplete theme.
|
||||
|
||||
That being said, I could imagine other microformats getting shortcodes and templates. A shortcode and/or partial for `h-cite`, `h-card`, etc. could work. [I've made a few microformats shortcodes](https://git.sr.ht/~seirdy/seirdy.one/tree/master/layouts/shortcodes) and could upstream simplified versions if there is sufficient interest.
|
17
content/notes/re-what-does-x-percent-of-issues-mean.md
Normal file
17
content/notes/re-what-does-x-percent-of-issues-mean.md
Normal file
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: "Re: what does x percent of issues mean?"
|
||||
date: 2022-07-20T17:01:29-07:00
|
||||
replyURI: "https://adrianroselli.com/2022/07/what-does-x-of-issues-mean.html"
|
||||
replyTitle: "What Does X% of Issues Mean?"
|
||||
replyType: "BlogPosting"
|
||||
replyAuthor: "Adrian Rosell"
|
||||
replyAuthorURI: "https://adrianroselli.com/"
|
||||
---
|
||||
Imagine asking a team of human auditors and disabled users to list all the accessibility issues they notice on a site. These people may list some WCAG failures, but might also list unique accessibility issues that aren't documented anywhere. They may phrase a single issue in a way that could cover a number of more specific issues (e.g. "this font makes my head hurt").
|
||||
|
||||
Then, run an automated scan on the same site. Combine the valid automated reported issues with the humans' reported issues. What percentage of this total could be addressed by the automated scan?
|
||||
|
||||
Repeat the exercise for a sample of sites, throw out the outliers, and average out the percentage. That's what "our tool catches <var>X%</var> of issues" could mean.
|
||||
|
||||
Now, I don't think most tools literally follow the process I described. I just described this example to illustrate the broader point that you don't need a "global list of issues" documented somewhere to make such a claim.
|
||||
|
Loading…
Reference in a new issue