fix og metadata

_includes/head-content.njk

@@ -13,8 +13,11 @@
 <meta property="og:site_name" content="{{ metadata.title }}" />
 <meta property="og:url" content="{{ metadata.url }}{{ page.url }}" />
 {% if image %}
-<meta property="og:image" content="/img/{{ image.src | toOgFilename }}" />
+<meta property="og:image" content="{{ metadata.url }}/img/{{ image.src | toOgFilename }}" />
 <meta property="og:image:alt" content="{{ image.alt }}" />
+{% else %}
+<meta property="og:image" content="{{ metadata.url }}/favicon.ico" />
+<meta property="og:image:alt" content="a teal bird icon" />
 {% endif %}
 
 <meta name="generator" content="{{ eleventy.generator }}">

src/posts/2026/2026-09-08-framer-accessibility.md

@@ -23,7 +23,7 @@ Accessibility **must** be built from the start of a project. Retrofitting a proj
 
 ## Semantic HTML
 
-Most HTML elements are semantic, that is, they convey meaning. Labeling something an `<h1>` doesn't just style it like a header; it also means that assistive tech can understand it to be a header (this also helps with SEO - a lot of things that improve accessibility improve SEO as well). See the Mozilla docs for a [list of semantic HTML elements](https://developer.mozilla.org/en-US/docs/Glossary/Semantics#semantic_elements).
+Most HTML elements are semantic, that is, they convey meaning. Labeling something an `<h1>` doesn't just style it like a header; it also means that AT can understand it to be a header (this also helps with SEO - a lot of things that improve accessibility improve SEO as well). See the Mozilla docs for a [list of semantic HTML elements](https://developer.mozilla.org/en-US/docs/Glossary/Semantics#semantic_elements).
 
 Notably, `<div>`s and `<span>`s are not semantic and convey no meaning. They are used for styling alone.
 
@@ -120,9 +120,9 @@ Accessible forms can be *hard*. They bring in challenges relating to labeling, v
 ### Forms in Framer
 
 1. **Labeling:** follow the pattern that Framer uses in its basic form for labeling. This will nest the form control inside the label.
-  - If you want an invisible label, you will need to write custom CSS.
+    - If you want an invisible label, you will need to write custom CSS.
 1. **Validation:** In the "Input" section of the right-hand sidebar, there is a dropdown for input type. There is also a toggle for whether the input is required.
-  - Note that setting an input to required will not add an asterisk or any other similar visual pattern to the label - doing this yourself is highly recommended. It also will not provide visual feedback to the user until clicking the "Submit" button, at which point an error message comes up - this can be a painful pattern for longer forms. Further visual feedback requires custom CSS.
+    - Note that setting an input to required will not add an asterisk or any other similar visual pattern to the label - doing this yourself is highly recommended. It also will not provide visual feedback to the user until clicking the "Submit" button, at which point an error message comes up - this can be a painful pattern for longer forms. Further visual feedback requires custom CSS.
 1. **Reading order:** follow the guidance for reading order discussed earlier.
 1. **Color:** since visual feedback for required feeds does not exist by default, this only becomes a concern if you write custom CSS.