12

Enhancing Accessibility and Optimizing SEO

When it comes to building web applications, we cannot disregard how important it is to ensure the applications are accessible to all users. By empowering those who rely on assistive technologies such as screen readers, we can further the impact our applications have. Not only does making an application available to a wider audience bring in more users, but it can also affect Search Engine Optimization (SEO). Therefore, it would be negligent to disregard how SvelteKit can help us make our applications accessible from the start.

To understand how we can best empower our users and how doing so can help boost our SEO, we should examine a few concepts. Firstly, we’ll see how the built-in compile-time checks can improve the accessibility of our application with little configuration on our end. We’ll also see how to best announce route changes, which can benefit tools such as screen readers. We’ll then briefly cover a few more tips that can benefit accessibility and wrap up with some simple tips for improving SEO. We’ll break it all apart into the following sections:

  • Compile-time checks
  • Announcing routes
  • Accessibility enhancements
  • SEO tips

Upon completing this chapter, we’ll have covered the essentials for ensuring your SvelteKit applications are accessible to a wide audience. Following the best practices outlined here will have the added benefit of improving SEO rankings.

Technical requirements

The complete code for this chapter is available on GitHub at: https://github.com/PacktPublishing/SvelteKit-Up-and-Running/tree/main/chapters/chapter12

Compile-Time Checks

When we installed our SvelteKit project, it came with a few opinionated enhancements out of the box. Of those enhancements, the compile-time checks can be of particular use to warn us of elements that have been poorly formed or are missing attributes. Upon making the suggested changes, we’ll notice that these warnings go away.

If you’ve paid attention to the recommendations from eslint or the output from builds, you may have noticed some warnings referring to A11y. This is the abbreviated term used for Accessibility. It refers to the A, the following 11 characters, and the y. In recognizing the importance of making applications accessible, the Svelte developers have opted to include sane behaviors by default as it contributes to a more open web. Before becoming frustrated with regular warnings, consider the convenience of having the application checked for a11y errors while not having to seek out our own solutions. Not only does building with a11y in mind help users but it also helps developers become better by recognizing which patterns are accessible and which are not.

If you’ve yet to see any of these issues, we can go back to one of our earliest examples and remove an alt attribute from an <img> element:

src/routes/+page.svelte

<script>
  import db from 'db';
  import url from 'img/demo.svg';
  let status = db.connection;
  let name = 'World';
</script>
<form>
  <label for="name" >What is your name?</label>
  <input type="text" class='name' bind:value={name} />
</form>
<h1>Hello, {name}!</h1>
<p>{status}</p>
<img src={url}>
// A11y: <img> element should have an alt attribute

In this example, the only change made is the removal of the alt attribute from the <img> tag at the very end. Most modern editors should alert you directly in the file, but if you’re not seeing this warning, you can view it directly in the output from the build by running npm run build in your terminal. Upon observing the build output, we will be able to discern the exact location of the problem and view a recommended fix.

These warnings don’t only apply to missing attributes on HTML elements either. We’ll also be alerted if form labels are associated with a control, if certain media types have captions, if attributes are given improper values, and more warnings than can be reasonably listed here. For a full list, see the resources at the end of this chapter. As we can see, the compile-time a11y checks can be incredibly useful in helping developers deliver accessible applications to as many users as possible.

Following the advice of compile-time check warnings is not the only way that we can improve a11y in our applications. We can also inform users of navigation events by updating the title of each page. By announcing route changes in the following way, we have the benefit of alerting users of screen readers while maintaining client-side navigation.

Announcing routes

Another strategy for ensuring a11y of our applications includes announcing our routes. This effectively means that all of our pages include a title so that screen readers can announce the new page to their users. With typical SSR applications, navigation consists of each new page being loaded when navigated to. With SvelteKit, navigation is handled by the client and so full-page reloads are not always necessary. This presents a dilemma for screen readers as they rely on a new title element to be present with each link clicked so that the page may be announced to users.

To play better with screen readers, we can insert a title into each new page we create using the <svelte:head> directive:

src/routes/+page.svelte

<script>
  import db from 'db';
  import url from 'img/demo.svg';
  let status = db.connection;
  let name = 'World';
</script>
<svelte:head>
  <title>Home</title>
</svelte:head>
<form>
  <label for="name" >What is your name?</label>
  <input type="text" class='name' bind:value={name} />
</form>
<h1>Hello, {name}!</h1>
<p>{status}</p>
<img src={url} alt='demo'>

On our application landing page, we’ve re-added the alt attribute to our <img> tag, but more importantly, we’ve set the page title to Home by including it in the <svelte:head> tag. Let’s make a similar change in another file so we can observe how this affects the browsing experience:

src/routes/(site)/about/+page.svelte

<svelte:head>
  <title>About</title>
</svelte:head>
<div class='wrapper'>
  <h1>About</h1>
  <p>
    Lorem ipsum dolor ...
  </p>
</div>

In our application’s About page, we’ve set the title by adding a <title> element with the appropriate text and surrounding it with <svelte:head> tags. These tags place the content within the document head. To see how this can affect the browsing experience, open the development version of the application and take note of the page title shown in your browser on the home page. Then, click About and observe how the title shown in the browser tab changes.

For screen reader applications, this small change allows them to alert users that they have navigated to a new route. Even for users who are not utilizing a screen reader, this is a noticeable improvement over the previous text showing only the site name. If a user were to bookmark a page on this site, the default text would now more accurately reflect the page in question. Not only is this helpful addition for all human users but it can also be a big boost to our application’s SEO, as many search engines will take into account page titles when indexing posts.

By announcing routes, we can greatly improve the experience of our application for its users. Next, let’s take a look at some other small adjustments that can make big improvements.

Accessibility enhancements

Not all developers nor all of those who utilize screen readers speak English as their primary language. As such, we should be able to adjust our application accordingly. Doing so is fairly straightforward and we can vastly improve the experience for users of assistive technology around the world by making a small note about the language our content is served in. By default, SvelteKit sets the language to English but we can quickly adjust it by changing the lang attribute on the <html> element in src/app.html:

src/app.html

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8" />
        <link rel="icon" href="%sveltekit.assets%/favicon.png" />
        <meta name="viewport" content="width=device-width" />
        %sveltekit.head%
    </head>
    <body data-sveltekit-preload-data="hover">
         <div style="display: contents">%sveltekit.body%</div>
    </body>
</html>

Note the <html> element at the top of the file with the lang attribute set. Setting the lang attribute to the appropriate language, such as fr for French or ar for Arabic, ensures that screen readers can correctly pronounce or translate the content.

One final a11y improvement we can make in our applications is allowing SvelteKit to manipulate the focus on HTML elements. Normally, when an application is rendered on the server, each new navigation event resets the focus. But in client-side rendered applications, the browser may not detect that a navigation event has occurred and therefore, focus will persist on whatever the currently focused element happens to be. To manage this with a11y in mind, SvelteKit resets focus to the <body> element – that is, unless an element has the autofocus attribute set, at which point that element will be given focus. Letting SvelteKit’s behavior take control of focus comes with the benefit of letting users of screen readers know that a navigation event has occurred.

When it comes to making our applications more accessible to a wider audience, it doesn’t take much effort on our part. Doing so improves the user experience, and all of the aforementioned improvements can also boost SEO rankings.

SEO Tips

Aside from making some small a11y improvements in our application, we can keep some other suggestions in mind. Firstly, we should make use of SvelteKit’s Server-Side Rendering (SSR) whenever possible. Doing so ensures the quick delivery of the application as well as makes content easier for search engines to parse. Of course, many search engines now have the capabilities to index client-side rendered content, but the speed and reliability of SSR cannot be discounted. We should only disable SSR if we have a valid reason to.

Another useful tip to consider is the performance of our application. For the most part, we can rely on Vite to tree-shake unused code out of our builds. Smaller bundle sizes mean fewer lines of code to deliver to the client and many search engines rank results based on asset delivery times. See the Resources section at the end of this chapter for tools that can deliver insights into your page speeds.

The final useful tip for improving SEO is to leave trailing slashes off route names. Having extra slashes can negatively impact page ranks, so unless you have a valid reason to, consider leaving the page option trailingSlash property alone. By following these few tips, we can be sure our SvelteKit application will rank highly in search engine results.

Summary

When it comes to building a successful web application, we must strive to make it accessible to all. The reasons for doing so may be purely selfish by attempting to capture as much of the market as possible, or egalitarian by trying to include users from all walks of the web. It could be that you simply want to be highly ranked in search engine results. Whatever the reasons may be, it’s a fairly straightforward process with SvelteKit. We’ve seen the warnings provided at compile time and we’ve learned about the benefits of both SEO and a11y when it comes to creating unique page titles. With a few SEO tips to keep in mind, it’s easy for our accessible apps to become known to the world.

Having wrapped up this chapter, we’ve covered nearly everything there is to discuss about SvelteKit. However, technology moves quickly so we can never truly be finished learning. By the time this book is published, there will likely have been more improvements and changes introduced into SvelteKit. To ensure you have the latest information, the next chapter will provide more resources, communities, and examples that are well worth your time to explore.

Resources

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.26.246