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.
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.
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.
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
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.
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
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?
- 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.