This page shows the source for this entry, with WebCore formatting language tags and attributes highlighted.
Accessibility is important
<img attachment="html_5.png" align="left">I recently read through the <a href="https://a11ymyths.com/"><abbr title="accessibility">a11y</abbr> myths</a>. They're quite interesting and should be required reading for managers running projects that develop web sites. From it, I learned about the evils of overlays (see the <a href="https://overlayfactsheet.com/">Overlay Fact Sheet</a>) and that there are really good resources out there, like <a href="https://www.w3.org/WAI/WCAG21/Understanding/conformance" source="W3C">Understanding Conformance</a> with WCAG 2.0 (Web Content Accessibility Guidelines). <bq>All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining if content satisfies them. Testing the Success Criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web.</bq> If you build custom controls, you should use <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA" source="MDN">ARIA</a>. That page includes the following note, <bq>Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states. However, if you choose to use ARIA, you are responsible for mimicking (the equivalent) browser behavior in script.</bq> If you do need to use ARIA, then there's a set of rules for its use in the article <a href="https://w3c.github.io/using-aria/#rule1" source="W3C">Notes on ARIA Use in HTML</a>. While we're on the topic of building your own custom controls instead of using the built-in HTML inputs, we can also talk about how <a href="https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#good_semantics">Good semantics</a> also goes a long way to having good accessibility, right out of the gate. So, go ahead and use <c>main</c>, <c>nav</c>, <c>header</c>, <c>footer</c>, <c>aside</c>, <c>section</c>, and <c>article</c>. There's some really good advice in there on writing clearly (e.g. use full month names and clarify abbreviations) as well as using meaningful text in links (e.g. don't just use "click" or "here").