Most website evaluation platforms are fundamentally similar – they read the code that a website is made from, and test it as written. Silktide differs because we don’t just read the code, we actually run it, and can therefore evaluate a web experience just like a person can.
How do we do this? With awesome technical magic-ery, of course! First, let’s talk about how traditional website evaluation platforms work.
What do other platforms do, and how does Silktide compare?
When a computer looks at a webpage it only sees the code – the HTML that makes up the page. You can see this for yourself on any page by right-clicking and selecting “View Page Source” in any of the main browsers.
Now, a web page is more than just its HTML. It’s a dynamic, changing, visually appealing construct of a combination of pieces of code, including JavaScript (code that makes elements on the page ‘do things’) and CSS (code that affects the styles and layouts of the elements on the page).
Without CSS (Cascading Style Sheets), your website will just look like an ugly mess. Without JavaScript, buttons, forms, animations, and any other dynamic elements won’t work.
Why is any of this important? Well, the main reason is that if a website testing tool is only looking at the HTML, it cannot experience a website with all dynamic elements and visual styles intact.
This is the fundamental way in which Silktide differs.
When Silktide tests a web page, it downloads the code and runs it in a browser, with all JavaScript and CSS. What we see, therefore, is the resulting page. All the information that’s in your browser is available to Silktide for evaluation.
We can see how big an image is. We can tell you if it has rounded corners, drop shadows, or any other styling applied to it.
More and more websites rely on JavaScript to even exist. Let’s take Twitter as an example. If you load any Twitter URL (try our Twitter feed), you may notice that some elements on the page load before others. This is because Twitter relies on JavaScript to work – it loads dynamic information in real-time and allows infinite scrolling.
Scroll down a bit, you’ll eventually get a spinner as it loads more Tweets. That’s JavaScript at work.
Now, what happens if we turn JavaScript off on Twitter?
We’re presented with an error message. If you look at the page source, you’ll see that there’s just this error message and no other content. Twitter simply doesn’t work without JavaScript enabled.
Now, let’s assume you’re using a computer to evaluate Twitter. All it will see is this basic HTML without content. That’s no good to you.
So, because Silktide can see the page after it’s fully rendered, it’s able to test it comprehensively.
Silktide uses real browsers to test on mobile devices
We talk about mobile accessibility testing elsewhere on our website, but it’s important to understand the limitations of other platforms. Part of the Web Content Accessibility Guidelines (WCAG 2.1) requires that web pages do not scroll in two dimensions on small screens.
That is to say, you should be able to scroll up and down, or side to side, but never both. You’ve probably experienced this on websites that are not mobile-friendly.
Usually, this happens when there is an image, a table, or some other element that is too wide for the screen width.
How does it work?
If you open Developer Tools in Chrome, you can choose to view your website as it would look rendered on a mobile device. You can change the size and choose different pre-made devices, or create your own.
The result looks like this:
Because Silktide can see this rendered, mobile version of a site, we can find issues like elements that are too large for the screen (remember, we said earlier that we can detect how big images and other elements actually are).
Again, other platforms would see the HTML code, but they’d not be able to figure out ‘this is too wide’.
The only way to know it’s too wide is to render the page in full, in a real browser, and evaluate it.
This picture shows the result of testing a page that found an issue with two-dimensional scrolling. In it, you can see the page content scrolls left and right, as well as up and down.
How else does Silktide’s technology help?
The advantage of testing a page once rendered carries a lot further than you may realize. For example, we know if part of a page is hidden, what colors are present on overlapping elements, and whether focus states are correctly implemented.
Hidden and visible elements
Take a menu bar that appears when you hover or click on it. Usually, that is accomplished with a piece of JavaScript that detects where the mouse is and changes the CSS to show or hide it.
The HTML doesn’t do this by itself, it needs JavaScript and CSS. If you’re only looking at the HTML, you cannot detect whether elements are hidden or visible.
Colors
Silktide can tell what color individual parts of a page are. The code doesn’t tell you that unless you run it along with the CSS.
This is especially useful for giving actual, accurate color contrast results between elements. Silktide doesn’t guess, it can tell you.
Silktide understands gradients, drop shadows, and stacked elements, while other platforms simply cannot because they don’t run the code.
Focus states
When navigating with a keyboard, it’s a WCAG requirement that elements become distinguished, so you know where your current focus is.
This is usually achieved by drawing a contrasting box around elements such as links when tabbing through a website with a keyboard.
Try pressing the Tab key on your keyboard now and you’ll see links become highlighted in turn. Silktide can detect these and tell you if you have implemented them or not.
Part of the upcoming WCAG 2.2 specifications actually goes further and requires specific contrast and sizes to be defined for focus states.
WCAC 2.2 also specifies that if an element is clickable, it must be at least 24 CSS pixels square in size, so it’s large enough that users don’t click on the wrong thing by accident.
Silktide will be able to test these accurately and let you know if they are big or contrasting enough. We’ll add that once the WCAG 2.2 spec is finalized and released.
Silktide can test complex user journeys
Because we’re running a real browser, we can talk to it. For example, we’re able to do things like click on cookie banners to dismiss them before we test a page. Cookie banners don’t even appear unless JavaScript is run, so other web evaluation software won’t even see them. We not only see the banners, but we teach our systems to dismiss them.
This also means we can teach our systems to do anything a human can.
For example, the way a traditional tool would work is to check each link in the code and visit them. But with that approach, things are missing.
Let’s say you fill in a search form on a website, press submit on the form button, and get a list of results. There’s no way ordinarily to visit the results page link. If you go to it directly (it might be something like ‘search.php’), nothing will happen, or you’ll get an error message because you didn’t submit the form.
Another example is once you have the results, you can use sliders and checkboxes to apply filters. So let’s say you have an e-commerce site with products listed. You can move a slider to change the price bracket or select to show only the blue products.
How would a computer know what to type in a search box? How would it know what to set the sliders to, or which filters to apply? A computer has no way, ordinarily, of filling in forms and seeing what’s behind them.
But with Silktide’s user journeys, we can teach it.
How user journey testing works
You can set up a journey of as many steps as you need. Let’s take a simplified version.
- Load the Search page, and wait 15 seconds
- Fill in the form with the word ‘t-shirts’
- Check that the results page contains products with ‘t-shirts’ in the title
What Silktide users see is a list of steps and their results. There’s a screenshot of what Silktide saw when it ran the step, a status (whether it worked or not), the uptime (amount of time it’s been working), and when it was last tested.
In the Inspector, you can actually see the results of each step. We test for accessibility, content, and all the other things Silktide can do for each step in the journey.
If any step in the user journey is found to be broken, it appears as a high priority error in the Silktide dashboard.
This essentially means that Silktide can find many more issues with a website than some other platforms. We think we’re fundamentally unique in this regard.
Silktide shows you where each issue is on each page
Silktide was built with usability in mind, and one of the main goals was to allow people to find and fix issues quickly. Silktide was designed from day one to show you each issue right on the web page where they occur.
For every single test in Silktide, across all our modules, you can see in the Inspector where they occur. Not just on the desktop version of your site, but also on mobile, and within the HTML.
You also get the explanation for each issue we find and a plain-English explanation of how to fix it.
Retest single pages immediately
Silktide gives you a number of ways to test your pages.
- Test your entire site automatically and on a schedule
- Integrate with your CMS and test each page automatically when you make a change
- Test pages before they go live in your browser using our browser extension
Most single-page tests take under 30 seconds, and your scores are updated in real-time. You also get progress bars for each retest you perform, so you can see how it’s getting on.
What does all this mean?
Silktide can:
- Test more things
- Present more accurate results
- Cover more aspects of WCAG
- Evaluate complex user journeys
- Test on mobile devices
- Show you every issue on each page
- Perform quick retests so you can see the results of your work almost immediately
- Change the way you think about automated web testing
So, I appreciate this article is somewhat long and a bit sales-y, but genuinely, this technology is really awesome, and we think you should take a look for yourself!
Questions? Request a demo of Silktide and tell us what you’re trying to achieve.
