Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


When is a page not a page? And when should it act like one?

By Liz Wilson, Posted on February 12, 2021 at 11:30 am

Liz Wilson

The Synergy developer interested in RESTful web services may have noticed a few intriguing things about this liminal era between Web 2.0 and Web 3.0. For starters, a page refresh is not guaranteed each time you navigate to some new corner of a website or app. When it comes to the “traditional” concerns of HTML, Javascript, and CSS—despite what The Offspring may claim—you no longer have to keep ‘em separated. The list of ways that frameworks like Vue, React, and Angular have changed both user and developer experience is extensive, and taken together, all these changes allow for unique and dynamic websites and applications.

That said, while innovation has the potential to take us further from the traditional experience of clicking a link and waiting for a new page to load, there are a few characteristics of those webpages from the early 2000s that the front-end folks would be amiss to innovate away from. Here are just a few!

1. Specific, Descriptive Title Elements

The HTML title element, demarcated by the <title> tag, is meant to provide a succinct description of the document that the browser has just rendered. If you are one of those people who has anywhere from 5 to 50 browser tabs open at any given moment, you probably rely heavily on page titles, as they appear in the tab next to the site’s custom icon.

A specific and descriptive page title is not just beneficial for compulsive tab openers like me, however. Unique titles with more, rather than less, information can improve the search engine optimization of your site. Additionally, page titles are often the first component that screen reader users will refer to in establishing where they are in a site. So adding a company name next to “Home” or “About Us” is a helpful enhancement, as is including information about changes to the page’s state.

For example:

<title>Error – password invalid – Acme Corp: Login</title>

The title element lives with other metadata in the “head” of the document, so it’s not displayed on the page and is therefore relatively easy to neglect. And when you’re working with tools like Angular and React to create single-page applications, you’ll find yourself with one HTML file in your project folder, which means just one <head> section where a title element would obviously be placed. Fortunately, most of these frameworks and libraries have developed tools for generating dynamic page titles.

ASP.NET Core Razor Pages

To ensure that your page titles are being updated dynamically, use the ViewData attribute either in the page’s model (as demonstrated in the documentation) or its .cshtml file. In either case, make sure that if you use Layout, the title element is reading from the ViewData dictionary. If you follow the standard instructions for creating a Razor Pages web application, this is the code you will see in the _Layout.cshtml file:

React

For a similar effect in your React app, install the React Helmet node package. Once that’s done, it’s a simple matter of importing Helmet and adding the document head information within <Helmet> tags within components as needed.

Angular

Similar to React, Angular projects contain a single index.html file, and that’s it for documents with the traditional head/body structure. Angular’s data binding can’t access anything outside of the body tag, so in order to display different titles as the user navigates around the app, you need to use the Title service, which is a very simple class consisting of two methods: getTitle() and setTitle(). The Angular documentation provides clear examples of how to incorporate this class into your application.

2. Semantic/Logical Headings

Whether your site is built with HTML and “vanilla” JavaScript or the client-side framework your cousin’s cousin created last week, at the end of the day, a document object model will be created by the web browser from HTML—whether that HTML was manually written by you or not. The DOM is a cross-platform interface that represents HTML as a tree structure by organizing all the markup’s elements, attributes, and text nodes into objects and creating a logical hierarchy from these objects. The technology was developed in the early days of JavaScript to enable client-side interactivity, and nowadays, the DOM also serves as the foundation for the browser’s accessibility tree, which is a critical layer that allows screen readers and other assistive technology to make sense of the contents of a website. Objects within an accessibility tree contain information ranging from what the specific element is (e.g., heading, input, etc.) to whether the element has a state (e.g., checked or unchecked, collapsed or expanded).

With that in mind, while current design trends indicate that the amount of text on each page remains in decline, it’s still a good idea to create a logical hierarchy of information and use different heading elements accordingly. This will not only benefit assistive technology users, but also the large swaths of us who have been conditioned to look for a big ol’ heading in a prominent position on the page. So even if the page is not technically a page, make sure the main heading is contained in a heading tag (probably an <h1> or <h2>) and the information that is less important is organized under the subordinate heading levels (<h2>, <h3>, <h4>…).

3. Logical Focus Order

In the same way that you may need to apply more thought with new web architectures, it’s very likely that you will have to expend some amount of effort to manage keyboard focus to replicate the way that focus operates in regular old HTML documents. In a traditional website (barring questionable use of CSS), a keyboard user can tab through each page in such a way that mimics the visual flow of information: left to right, top to bottom. In a single-page application where new HTML documents are not actually being loaded in the browser, there is nothing that would necessarily prompt keyboard focus to jump to an element at the top of a new page, because there is no new page. The Angular website (built, naturally, with Angular) provides us with an example of this. If you tab to the footer section from Home and select About, rather than hopping up to something intuitive, like the links at the top of that “page,” your next tab will take you to the next item in the list of footer links.

There are other potential issues relating to mutable content, including focus effectively disappearing, or users getting shot back up to the top of a section if a button is replaced by some other UI component.

Again, today’s popular libraries and frameworks propose techniques for providing a good experience for keyboard users:

To conclude, there is no reason for the not-pages that make up your single-page application to look like they were built in 2006. However, a case can be made for ensuring that certain aspects of the early web experience are not thrown away with the bathwater.1


1The bathwater consists of jQuery, Flash, and frames.


Leave a Reply

Your email address will not be published. Required fields are marked *

*

Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives