Please support "skip to main content" on your docs site
technicalwriting.dev
technicalwriting.dev
HTML defines a <main> tag: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ma...
> The <main> HTML element represents the dominant content of the <body> of a document. The main content area consists of content that is directly related to or expands upon the central topic of a document, or the central functionality of an application.
(And, yes, the above page has a "Skip to main content" link that shows when I hit tab.)
The thing is, <main> is how the page (via HTML) indicates what the main content is. The browser can have its own keystroke or semantics to find the main content.
Until then, skip links aren't the worst idea.
Every site implementing this slightly differently is a recipe for future frustration.
Years ago I tried to track down the origin of this practice and at the time all I could come up with was a wishful blog post empathizing with people using screen readers, not an actual user study or formal accessibility research.
Sometimes, this can be extremely non-obvious and involve a lot of fiddling about, virtual environments, copying files, setting paths or ports etc. Especially when the language or development tooling is unfamiliar. But it's almost insultingly obvious to someone who has developed their workflow for years on the project.
A good example of how not to do it is Sigrok, which has a pile of separate libraries, and instructions on building and installing but not much about whether that's the most effective way to build and debug. Especially as the library you, a prospective hacker, probably want to develop with is a lower-level one to add device support. Eventually you can piece together something, but it often feels like you're not quite doing it "as expected" (or sometimes it's just that fiddly).
A good example is Tridactyl, which has a "build and install it" section, but also has a dedicated "development loop" section that tells you to use "yarn run (re)build && yarn run run"
On day 1 of this journey I realized how important the Tab key is for website navigation. Tab lets you jump between focusable elements such as links and buttons. If you’re viewing this page from a computer with a keyboard you can try it now [...]
Just to make sure this is not a Firefox issue, I opened the page in Safari, pushed <TAB>, and nothing happened. At this point I'm not sure if the author is performing some elaborate prank on me. I agree that accessibility is important, and being able to quickly navigate with tabs and arrow keys is something that many modern web apps fail at, but some of them do pretty well! (Slack is surprisingly good at placing focus on the most commonly used widgets of the app, and they even provide a mini tutorial on your first attempt at keyboard navigation).
Assuming that this article is not intentionally breaking keyboard navigation, they should hold themselves to the same standards they have outlined.
You can enable it via System Settings -> Keyboard -> 'Keyboard navigation' toggle
Then it works exactly the way the author described (which is also the default on Windows and Linux, I believe)
Now I am curious why Mac OS has defaults that seemingly break accessibility on some websites? This is the first time in recent memory that I've experienced a page not responding to tab keys at all. Your suggestion remedied the issue on Firefox, but not on Safari for some reason.
[1] https://www.mayank.co/blog/safari-focus#keyboard-navigation
To be more specific, it only navigates between form elements (including <button>) by default. I was curious why Tab was taking me all over a StackOverflow page but not the one linked here.
Unfortunately a lot of websites have no searchable text on their links. Sometimes the problem is that it's an icon; other times the problem is that the text is not added in a way that allows search (I don't HTML enough to know all the ways). This is in addition to all the clickable elements that aren't tabbable, ugh.
I've also found a significant number of scrolling/sliding and menu-like elements where tabbing does weird things (partial scroll, not adjacent, etc.).
There was a browser called xxxterm (later called xombrero) that did this pretty nicely. There was a hot key that showed a little overlay of a number on each link. Type that number and it clicks the link.
Sadly the project was discontinued. It was one of my favorite browsers.
If you really care about all websites having roughly the same key binding experience then you need to use an extension or custom browser.
(Assume I'm talking about for profit software here)
In fact, web accessibility best-practices also aim to reduce barriers for folks who have e.g. ADHD, autism, dyscalculia, trauma disorders, poor network connections, cheap/low-grade devices, difficulties with mobility and motor control, stroke, color blindness, memory impairments, among many, many others -- ultimately lots, and lots, and lots of people. Also, web accessibility standards cover not only physical and intellectual/cognitive disabilities but also socio-economic and situational impairments (e.g. you're situationally one-handed because you're carrying a baby).
On top of that, it turns out that just as ramps and lifts are quite helpful for nondisabled (situationally or otherwise) folks in many circumstances, so too are websites that don't violate web and accessibility standards by hijacking browser functionality and behave predictably.
#2. The idea that folks have about how "those members of the population are a tiny portion and the business value is minor" is very strange and patently false: the vast majority of people on planet earth will experience disability at some point in their lives. One in ten Americans has a disability, that rises sharply with age to nearly 1 in 2 for older Americans. These aren't difficult stats to find sources for -- so I think this particular argument constitutes a certain level of willful ignorance underlying much of the difficulty disability advocates face.
Example from a project I worked on: I needed to test that when a button is clicked that the app showed a spinner when loading and then the content when the API call completed successfully. The spinner component was just an SVG with no obvious way to select it without adding a test-id, so instead I refactored the app to use an aria-busy attribute [2] in the container where the content is loading. The test then becomes something like this:
test('shows spinner while loading and content after API call', async () => {
render(<Example />);
userEvent.click(screen.getByRole('button', { name: /load content/i }));
expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'true');
await waitFor(() => {
expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'false');
expect(screen.getByText(/content loaded/i)).toBeInTheDocument();
});
});
At a previous job, that was the justification for a mandate to make sure our website and mobile app was accessible prior to its general availability. (It's also the right thing, as we knew, but the existence of a legal requirement tends to give doing the right thing a lot more priority in a team's backlog. So there's at least one case of the law working as designed.)
See also https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac... -- the experience I'm talking about was prior to the mentioned 9th Circuit ruling or the Supreme Court's 2019 declining of the appeal, but the laws were on the books already. I don't remember exactly whether the Target case is what was mentioned as a motivating factor to us, but it might have been: <https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...>
(I say 'possibly underenforced' because I don't really know enough about the accessibility landscape, but I somehow doubt that every customer unlawfully prevented from accessing services that the ADA covers actually sues...)
Websites just don't have that level of red tape to launch. People do not need a government issued certificate of minimum level of compliance to launch. There are way too many sites for pretty much any government to monitor for ADA compliance. There's probably a way to report issues, but who has the time to look up where to do that? Some part of my foggy memory also thinks there's a caveat for the size of the company running a website about how strict compliance needs to be, but that might getting confused with cookie banners???
This word is inaccessible to those unfamiliar with the abbreviation, such as many non-native speakers who would have difficulty guessing.
Just write "accessibility".
If you compare Chrome Dev Tools now to what was available 10 years ago, the difference in capabilities was stark. My memory is fuzzy, but I don't think it had support for anything related to accessibility, but over the years they kept adding new features to make it easier to build accessible websites.
I think it's an education gap which can be closed with better tools and documentation.
I think this survey is useful for looking at other preferences of screen reader users (even if it is just one survey) https://webaim.org/projects/screenreadersurvey/
Well, there goes so many library/plugins that specifically use the title attribute as roll over fly outs.
Consider a large navigation menu appearing before the content in the DOM and having to tab all the way through it to follow a link on every page.
Now get off my lawn, I miss Web1.0 and 2.0.
Honestly, I rarely use skip links, because they sometimes don't even work and just leave my screen reader on the skip link, so I just use headings and landmarks.
Sadly most programs make search a heavyweight operation.
But search at least usually takes me close to what I need from where I can tab as required.
When I navigated to the other example accesibility links you provided (such as Google and Wikipedia), the first tab press did jump first to the "jump to content" link.
Isn’t that the whole point of the <main> tag (and its associated ARIA role), so that browsers can know which content is the “main” content?
I mention this bc I've yelled into the void before about not being able to navigate webpages consistently until I stumbled on vimium.
[1] https://addons.mozilla.org/en-GB/firefox/addon/vimium-ff/