15 03, 2018

OUTC18: Beacon on Accessibility

By | 2018-03-14T12:40:16+00:00 March 15th, 2018|Categories: Higher Education|Tags: , |Comments Off on OUTC18: Beacon on Accessibility

There is no doubt that ADA compliance and accessibility is the hot button issue for today’s college and university websites. Compelled by section 508 of the Rehabilitation Act, federal agencies and institutions that receive federal funding must make their websites accessible to all users. Questions remain. For example, what does web accessibility look like? And how do we get there?

At this year’s OmniUpdate User Training Conference, Keana Lynch, Beacon’s Director of UX Design & Development will draw on a wealth of experience with accessibility issues, offering valuable advice on recognizing issues and developing strategies to reach and maintain accessibility goals.  From site evaluation to action plan, get the perspective and tools you need to get ahead of any future user issues or litigation.

OUTC18 will take place from March 25 – 29 at the Hyatt Regency Orange County in Anaheim, CA. The OmniUpdate User Training Conference brings together higher ed content managers from all over the country to discuss the latest news, strategies and best practices for college and university websites. Broaden your knowledge base with workshops and training sessions and network with like-minded professionals from all across the higher ed space. Registration closes Friday, March 16. Register HERE.

10 03, 2015

Building a paginated listing with only HTML and CSS for Responsive Design

By | 2017-06-16T12:34:34+00:00 March 10th, 2015|Categories: Web Development|Tags: , , , , , , , , , , |Comments Off on Building a paginated listing with only HTML and CSS for Responsive Design

Most paginated listings on the web are managed either with server side logic, javascript, or a combination of both. With the first option, the user’s browser wait on network traffic back to the server and back down again. Even if the data is as succinct as possible, a bad connection or crowded wi-fi can make your site look slow. An example of this sort of method can be seen on google search results. Each page requires a new querystring and page load. With the second option, the html for each page can be loaded into the dom on the first page load and then a script will manage displaying each separate page or section of data as the user interacts with the page’s navigation. The downside of this approach is that if script is disabled, as is so often the case on computers with high security settings, the only ways to recover are to display either a single page at a time using server side logic, or to display the entire listing without pagination at all, which can make for an enormously long page. The last option uses a combination of both, and can result in a smoother user experience, but also then suffers from the drawbacks of both. This last option can be seen in effect by scrolling to the bottom of a facebook page; the first “page” of content is loaded up first, and only by scrolling down is additional content then called down from the server and added to the page via javascript.

I think that’s enough of the bad news! You’re here to find a way to circumvent all of these headaches so that you can give even the most restrictive browsers as much access to your content and with the very best user experience possible.

Lets get started shall we?

We’ll start with a sample of how you might list results currently. For ease of reading and instruction we’ll keep the content short and sweet, and we’ll keep our pages limited to 3 results per page.

We have to make a few changes to this to make it work in pages. Let see what that looks like:

Now that we’ve got them separated into page containers there’s one thing that’s important to make note of. You may have noticed that page1 is actually listed last. It’s also important to note that the order of all pages that aren’t the first page isn’t relevant to this process, only that the page you want displayed by default, or first, is the last child of the .pages container. This is so that we can take advantage of a special kind of css selector in order to get around css’s inability to select nodes up the dom. If you intend to use my advanced method below however, it is necessary to display the pages in order with the only exception still being that the first page be listed last.

That selector is called the General Sibling selector, which is the last selector outlined here. This selector selects all elements that match the right hand selector that are siblings of the left hand selector only as long as they appear in the html after the left hand selector. In our sample, a rule for “#page3 ~ .page” would select #page2, and #page1, but “#page2 ~ .page” would only select #page1.

We’re going to use that selector to hide all pages that aren’t the first one.

This ensures that when the webpage loads, only one page of your list will display, and that it will be the first page. In order to give the user a way to change the pages, we need to create a page listing in our html.

The new .pageNav element can go anywhere on the page, but it must not be added as the last child of the .pages div so that our previous rules will continue to show and hide the correct divs. To get those links to functionally show their respective pages we need to make an additional tweak to our css:

These new rules showcase the two selectors that make this whole thing work. One we’ve already discussed. The new one is the :target selector, which applies to an element if it has an id that matches the hashtag (for lack of a better word) in the url. When one of the nav links is clicked, it appends it’s href to the url. A live demo of this in action is available here.

The key to this html/css trick is just outputting your first page last, which is easily possible in most content management systems. The rest of it is very simple. This solution is responsive, is 508 compliant, and search engine friendly.

Another benefit this method has over javascript is that it take advantage of the browser’s ability to remember the previous page’s hash tag, which means that if a user follows a link in your paginated listing, and clicks the back button, they’ll retain their active page.

To be fair to the other pagination methods above, this too comes with a drawback, although it is in my opinion a minor drawback. In order for this method to be fully encapsulated by html and css all html content for all pages must be loaded on the first page load, which can slow down the page if the content of each page is exceptionally large. In the case of most paginated listings however, that is rarely the case.


Now that the base concepts have been outlined, I’d like to show you what I consider to be the correct and most exhaustive solution for applying this sort of method to a responsive site where we don’t want to limit the user to only the core html/css experience if they’ve allowed scripts on their browser.

NOTE: This implementation uses jQuery for ease of understanding, and portability. jQuery is, however, a very large library and might not be the most efficient way of accomplishing this from a performance perspective.

First, lets look at some easy changes to the html:

Specifically what we’ve done here is add previous and next buttons to each page. The reason these have been added here, and not with the rest of the navigation buttons is because without javascript enabled, we can’t properly style or control the behavior of them dynamically, so we need static but functional links that we’ll only render on our mobile view. Functionally, at smaller screen sizes (like smart phones), requiring the user to click on one of several small links next to other small links can be frustrating, and giving them the same pagination functionality, but restricting them to only previous and next navigation is a simple process that drastically improves user experience. For all of these changes, we’ll need to update our css:

You’ll notice several new lines, so lets break them down.

  • The first change is to our existing rules. We’ve added :not(.js) to the .cssPagination selector. This is going to enable us to maintain css control over the general layout of the elements, even if (when) we upgrade the functionality with javascript.
  • Next we’ve taken the liberty to hide the next and previous buttons by default, so that we don’t have two lines of navigation controls for the user to interact with.
  • The next 3 lines are going to work specifically with the two new classes (js and paginationActive) in order to give our script the ability to manage pagination without having to get its hands dirty mucking about with styles.
  • Last is the media query. If you’re familiar with responsive design and development you’re already familiar with what this does. For those of you who might not recognize the tag: this call “@media screen and (max-width: 480px)” tells the browser to only enable these rules when the device reading the browser has a screen, and the current resolution is 480 pixels wide or less. For more information on media queries read here.

Lastly we’ve added a script section, which will take over pagination when scripts are enabled (and in our case when jQuery is present):

To see this all together in action click here. To see how this setup looks without javascript enabled all you need to do is set addInjQuery at the top of the script file to false. The demo also demonstrates how the previous and next buttons respond in a responsive manner to the available screen resolution both with and without the script enabled.

NOTE: To use this script as is, I recommend using the version shown here and not the one in the demo, as it is hard-coded to a specific version of jQuery, rather than this version which is compatible with virtually any version of jQuery that you might already have on your site.

The script that was added now only works when scripts are enabled and jQuery is available. This allows the content to be enhanced progressively depending on what features are or aren’t enabled on your user’s browser and device. This ensures that no matter what device or browser your client is using they will get the best possible experience from your site in the most efficient manner possible.

To recap this method for how to paginate a listing on a web page is responsive, not dependant on javascript, not dependant on posts to the server (either synchronous or asynchronous), 508 compliant, and in most cases incredibly efficient. It is also heavily customizable to fit in any website design in any language.

That’s all for this topic. To read more by some of our other incredibly talented staff see below:

John Vine

John Vine been developing website and web applications since 2010. He grew up in Greensboro, NC and was very happy to be able to return here after graduating from Full Sail University with a bachelors in game development. John prefers the open feeling of his motorcycle which he rides right up until the cold of winter forces him back into his car. He is a Green Bay Packers fan and hopes to one day have season tickets.