On Macs, the tradition is for applications to only include input fields and buttons in the tab order. Following this convention in a web browser means links are not in the tab order. If you're trying to test the keyboard accessibility of websites, this can be confusing and an inconvenience. How to change this behavior varies by browser.
Safari - In Safari Preferences, go to Advanced and check "Press Tab to highlight each item on a webpage."
Firefox - In the macOS System Preferences (version 12 "Monterey" and earlier), go...
I recently heard about Atkinson Hyperlegible, a free font created for the Braille Institute. There are a number of "accessibility" fonts meant to make text more readable by people with learning disabilities like dyslexia but this was the first I had heard of designed to be more readable by those with low vision. Some features of this font may also help with learning disabilities but in other ways it may be no better than more commonly used fonts.
The current (Drupal 7) OpenScholar Accordion widget is decent, from an accessibility perspective, but it has a glaring problem for sighted keyboard users.
A Problem
If a panel in the accordion contains elements in the tab order, typically links, they remain in the tab order, even when the panel is collapsed. When these visually-hidden controls have focus, a user can't tell where focus is within the page, it has disappeared.
HTML <table> elements are meant for tabular data, not for creating two-dimensional layouts. However, OpenScholar's only other non-code solution to have content in columns is to not write it in a Page but to write each piece in a Custom HTML widget and use the Layout to arrange them. Content in widgets is much harder to manage than content in Pages (or other post types).
I've found another issue with VoiceOver and Safari involving <label> elements and the CSS display property. If a <label> is inside a table cell and has display: table, the input's label is not read, despite Safari's Node > Accessibility information displaying the correct label.
While drafting a sample web form, I found a problem with how VoiceOver was reading the labels for some of the inputs. For example, a text field was labeled "First Name" but on the text field VoiceOver was saying "First Nameand one more item, edit text" with the word "Name" mispronounced and smooshed with the word "and." If I navigated to the <label> element itself, VoiceOver read it correctly, it was only wrong when it was read as the accessible name of the input field. Other inputs in the form didn't have this problem but then I wrote another input example that I...
While looking for information about uses of the title attribute, I learned about the concept of alternative style sheets. Basically, you can name an external stylesheet or a style block in the page with the title...
