Here, you’ll find insights on programming languages, frameworks, and techniques that shape the web and software landscape. Whether you’re a developer looking to refine your skills or simply curious about how things work behind the scenes, this space offers practical knowledge and thoughtful perspectives.
In March of 2024, the Google Chrome Team replaced one of their original Core Web Vitals with one they had been testing for two years: Interaction to Next Paint (INP). With this move, INP became the new gold standard for testing the âsnappinessâ of usersâ experience on the web. But what is a Core Web Vital, and why does it matter?
What is a Core Web Vital?
Web Vitals are metrics put out by Google intended to help website owners understand the quality of experience they are delivering to their users. Some of these metrics apply less to some websites than others, so Google has designated three of these which they consider to be relevant to every website as Core Web Vitals. These cover three categories of user experience: loading, interactivity, and visual stability. INP is the metric corresponding to âinteractivity.â Importantly, this is not just about user experience; Core Web Vitals also affect a siteâs page ranking in Google.Â
What is INP?
INP measures (with a couple technical exceptions) the duration of the longest interaction on a page. Interactions primarily consist of clicks (or taps on mobile) and key presses, and the interaction length is measured as how long the page takes to do what it needs to do after the user initiates the interaction. Thus, if a page has a bad INP, this does not mean that all interaction lengths are long, but rather that there exists some interaction which takes an inordinately long amount of time.
How can I measure and improve my siteâs INP?
As a site owner, though there are many ways to measure INP, all you need to do is enter your site URL into Pagespeed Insights, which is a tool run by Google themselves that will tell you how your site performs across all three Core Web Vitals. If they tell you that you have a good score, you should have nothing to worry about. If not, you may need to do some digging on what exactly the issue is that theyâre detecting. There is no one-size-fits-all resolution to this sort of issue, but a competent developer (like those at Atlantic BT!) should be able to investigate where the slow interactions are and determine both why theyâre slow and how they can be made faster. They’ll comb through the site, looking at every interaction the user has with the page, including input delays, button clicks, and more. These links might be a good place to start if you’re introducing the issue to a developer:
While fixing INP may not be simple, it is certainly worth the effort put into improving user experience and search result ranking. Since INP just replaced another related-but-different Core Web Vital, now is a good time to re-evaluate your site and see if anything needs to be done. If there is something you need to fix, and you donât have the capacity to handle it in-house, consider letting us know! Weâd love to figure out how we can help.
If you spend time in Chrome DevTools console tab you may have noticed these warnings “Third-party cookie will be blocked. Learn more in the Issues tab.”
In this post we’re going to cover some beginning details a website developer is considering. To be certain, there will be some nitty-gritty details not covered here, but it will give you a general lay of the land and link to further details. If you need to know more on what these cookies are, check out my other post: The State of Third Party Cookies in Browsers.
Third-party cookies are created by domains other than the one you are directly visiting. These cookies are mostly used for tracking users across different websites, enabling businesses to serve targeted advertisements based on browsing history and preferences. For more basic information, you can read this post.
Does My Site Have Affected Third-Party Cookies?
We have the problem, third-party cookies are going the way of the dinosaurs. Now, what needs to be done to assess the likelihood your site is affected? What steps may need to be taken to continue using the functionality they enable?
Testing Existing Cookies in Chrome DevTools
The easiest way to view cookies on a site and see if they will be blocked, either by browsers that currently block third-party cookies or browsers that may and are planning to block cookies in the future, is to:
Open up Chrome DevTools in the Chrome browser.
Click to open the Application tab.
Open up the Cookies section in the left-hand sidebar and select a domain.
From there, find the “Only show cookies with an issue” checkbox and mark it checked. This will filter down to only cookies which are currently blocked (in FF and Safari for example) and possibly will be blocked in the future (in Chrome and Edge for example).
If you right-click on one of the affected cookie rows, you’ll see you can select from “Show Requests With This Cookie” and “Show issue associated with this cookie”.
The first option will bring you to the network tab, with the results filtered down to the requests where that cookie was used. The second will open up the Issues tab, which will list all the cookies that had issues on the page and all the requests that had issues.
Another, slightly more involved way of auditing cookies is to use Google’s Privacy Sandbox. It will give you more information on why the cookie would be blocked.
Once you’ve identified the cookies that will be affected, you’ll need to evaluate each one to determine the appropriate course of action.
In some cases, it might be a cookie that your site has issued, but was not specified as not cross domain during its setup.
In other instances, the cookie might have been set by a third party. For these, you’ll need to contact the respective company to find out their plans for adapting to the third-party cookie phaseout.
Options for Privacy Preserving Solutions
As usual there are different ways to address this issue with browsers implementing different specifications.
If your third-party cookies are utilized on a select few closely related websites, consider leveraging the Storage Access API and/or Related Website Sets to enable cross-site cookie access exclusively for those specific sites.Â
The Storage Access API involves a user-friendly prompt asking for permission to allow third-party cookies on a case-by-case basis and is supported by all major browsers.
Think of Related Website Sets as an enhancement to the Storage Access API. It operates similarly, allowing cross-site cookie access, but without requiring user permission each time for sites within the set. This does not have cross browser support. It is currently only supported by Chrome and Edge using the requestStorageAccessFor API.
For third-party cookies that are directly tied to the main websites where they are created, you might want to consider using Cookies Having Independent Partitioned State (CHIPS), or partitioned cookies. This method involves adding a ‘partitioned’ attribute to your existing cross-site cookies, which then places them in a separate storage partition for each top level site. This setup allows unrestricted use of these cookies, although they remain isolated and cannot be shared with other sites. This is only supported in Chrome and Edge.
Third-party cookies are small text files created by domains other than the one you are directly visiting. There are various reasons they are used:
Tracking and Analytics: Third-party cookies can track a user’s browsing activities across multiple websites. This data is valuable for analytics, helping website owners understand user behavior and improve their site’s performance and content.
Advertising: Perhaps the most well-known use of these cookies is in targeted advertising. Advertisers use these cookies to gather information about your interests based on the sites you visit and the actions you take. This allows them to show you more relevant ads across different websites, attempting to increase engagement and conversion rates.
Social Media Features: Websites might use them to enable social media functionalities, such as “Like” buttons, sharing capabilities, and other interactive elements that link back to social media platforms.
Content Personalization: Similar to advertising, third-party cookies can be used to personalize content across websites. For example, a news site might modify what you see based on the articles you’ve read on other sites.
Cross-Site Login: Some services use them to allow users to log in to various websites with the same credentials without having to authenticate separately on each site.
Why are Third-Party Cookies Being Phased Out?
Privacy.
Digital privacy has reached a tipping point and become a culturally visible concern. Companies compiling detailed personal profiles with cookies has raised alarms about individual privacy rights. Third-party cookies, which track users’ across different sites, often without explicit consent or clear understanding from users, is an example of the lack of digital privacy that affects anyone using a browser.
This has led to laws and regulations like GDPR in the EU and CCPA in California that put strict requirements on how personal data can be collected, processed, and stored; consent must be clear before data can be used, and users have more control of their personal data.
Effects of Removing
Removing third-party cookies will significantly affect how websites track user behavior across the internet. Currently, many businesses rely on these cookies for targeted advertising and analytics. Without these cookies:
Advertisers will find it harder to track user behavior across multiple sites.
Publishers may see a decrease in advertising revenue, since personalized ads tend to generate higher revenue.
Users will likely notice a difference in how personalized their web experiences are, with potentially fewer targeted ads.
The Current State of Third-Party Cookies
Some browsers have already cut out third-party cookies by default. The notable ones are Firefox and Safari.
Some browsers are slowly moving towards removing them. They are Chrome and Edge.
Let’s look at browsers North American market share for the last year ending April 2024. Data from Statcounter Global Stats.
Line graph showing the percentage use of the top 4 browsers in North America.
The gorilla in the room is Chrome, with a 51% average market share over the year. They have a detailed and current plan (it has been delayed multiple times) to phase out third-party cookies by early 2025. No matter your site, if you use them you need to look into this as you most likely have a large chunk of Chrome users.
The browser with the largest share of use and has blocked third-party cookies is Safari, with a 31% average market share over the year.
Microsoft’s Edge browser has about an 8% average market share, but by default they currently don’t block these cookies. Users can manually set cookies to be blocked, and they have started the process of warning users and developers that third-party cookies will be phased out.
Firefox has about a 4% average market share and also blocks these cookies by default.
Your specific site browser percentages may differ, but you may already have some motivation to start implementing alternatives to third-party cookies.
Do you need help? We can do a technical audit and start the conversation.
Exploratory testing is an unscripted, manual testing method that helps teams deliver higher quality software. It relies on the creativity, intuition, and domain knowledge of the tester to analyze the software and identify things like unexpected defects, edge cases, and accessibility concerns. While planned/scripted tests and automated testing ensure that known features and functionalities work as expected, exploratory testing allows testers to uncover hidden issues as they dynamically probe the software’s functionality and design. By simulating real-world usage, exploratory testing also helps uncover usability issues that might affect the end-user experience. This testing method complements other testing techniques well, especially when there is not enough time to create comprehensive scripted tests for every possible scenario. Since exploratory testing does not require extensive test case preparation, it can also be more cost-effective than traditional testing methods. Due to its flexibility and adaptability, testers can quickly adjust their approach based on the latest software updates or changes.
Conducting Exploratory Testing
Exploratory testing is one of my favorite methods. It encourages testers to think outside the box and explore software in a natural, intuitive way. Here are some tips for conducting exploratory testing:
Set the test environment: Start by preparing your testing environment. Ensure you have access to the latest software build, any necessary testing tools, and a clear understanding of the software’s objectives and functionalities.
Outline test areas: Because exploratory testing is less formal, it can sometimes lack detailed documentation. Create a loose outline of the objectives and scope of your exploratory testing. The outline could be a simple list of features that are ready for testing. Having an outline can help you stay focused while allowing flexibility in your approach.
Go play: Start exploring the software. Interact with the software as an end-user would. Guess where potential bugs might exist based on factors such as complexity, areas of frequent change, or past issues, and spend some time testing those areas.Â
Log bugs: Document any issues or unexpected behavior you encounter while testing. Provide thorough notes in the bug report to give developers the information needed to reproduce and fix the issues.
Follow the process: Follow your standard process for managing bugs that are logged. Provide any additional information needed by developers, test submitted fixes, and track each bug to resolution. Â
Collaborate with Developers: Maintain open communication with the development team throughout the testing process. A collaborative approach between tester and developer helps ensure that any identified issues are addressed quickly and effectively.
Learn: Continuously learn from your testing experiences and refine your approach. The more you test, the more you increase your knowledge of the software and the better you become at identifying potential issues and improving your testing effectiveness.
Best Practices
Though exploratory testing is unscripted, there are some things you can do to assure it is effective. Keep these best practices in mind.
Have the right mindset: Approach the software with a mindset of exploration rather than following predetermined test cases.Â
Focus on real-world usage: Simulate real-world scenarios and user workflows, trying to replicate how actual users might interact with the software. This approach can uncover bugs that arise from unexpected user behavior or edge cases that were not accounted for in the initial design.
Do ad-hoc testing: Rely on intuition, experience, and creativity to identify potential issues. Deliberately introduce randomness into the testing approach by varying inputs, configurations, or sequences of actions.Â
Explore boundary conditions: Test boundary conditions, such as maximum and minimum input values, to see how the software behaves under extreme circumstances. Bugs are often discovered at these boundaries.
Use various test environments: Test the software on different operating systems, browsers, and devices. Bugs may manifest differently depending on the environment, so exploring these variations can uncover hidden issues.
Have a feedback loop: Continuously provide feedback to developers based on findings during exploratory testing. Again, this fosters collaboration and allows developers to address issues as they are discovered.
Exploratory testing remains an essential part of software testing. Its ability to uncover hidden bugs and improve the user experience makes it invaluable for testers. By incorporating exploratory testing into your testing strategy, you can ensure that your software is robust, reliable, and user-friendly.
Making your website accessible to all users is more important than ever. Despite this, over 96% of the worldâs top one million web pages fall short of website accessibility standards, leaving a significant portion of the global population unable to fully engage with online content. Creating inclusive online environments is not just a moral obligation but also a legal requirement in many regions. In 2024, the new European Accessibility Act (EAA) and the Web Content Accessibility Guidelines (WCAG) 2.2 updates set the standards for making digital content accessible. By embracing website accessibility, you can enhance usability, expand your user base, and comply with international regulations.
Why make your website accessible?
Designing for accessibility isn’t just about compliance; it’s about inclusivity and ensuring that everyone can use and benefit from your website. According to the World Health Organization, 16% of the worldâs population, or 1 in 6 people, experience significant disability. In the United States, the Centers for Disease Control and Prevention (CDC) reports that 1 in 4 people, or 27%, have a disability. Given these statistics, itâs clear that accessibility is a critical consideration.
Everyone will experience a temporary or permanent disability at some point in their life. Whether it’s a broken arm, age-related impairments, or situational disabilities like a noisy environment, designing for website accessibility ensures that your website remains usable for a wide range of users.
Key Takeaway: Creating accessible designs means you expand your user base and increase usability for everyone!
Who needs an accessible website under the law?
In the United States, the Americans with Disabilities Act (ADA) mandates that state and local governments must be accessible under Title I. Additionally, any business open to the public must comply under Title III. This includes a wide range of entities:
State and Local Government: All government websites and digital services must be accessible.
Private companies funded by the government: These entities are required to ensure their digital presence is accessible.
Airlines: The Department of Transportation Rule #2 requires airline websites and automated kiosks at U.S. airports to be accessible to passengers with disabilities.
Universities: The ADA mandates that educational institutions provide equal access to their programs, services, and activities for students, faculty and visitors with disabilities. This includes making college websites user-friendly so everyone can access essential information and resources without barriers.
Websites are increasingly becoming accepted as public spaces, and thus, must be accessible to comply with the ADA.. Public websites may include those for:
Retail
Restaurants
Hotels, Inns, and Motels
Hospitals and Medical Offices
Banks
Theaters and Sports Arenas
European Accessibility Act (EAA)
The European Accessibility Act (EAA) is a significant piece of legislation that aims to improve website accessibility and of a wide range of products and services within the European Union. Compliance enforcement begins on June 28th, 2025. The EAA sets clear guidelines and standards that must be met, ensuring that digital services are accessible to everyone, including those with disabilities.
The European Accessibility Act Applies to the following products and services within the European Union:
E-Commerce – Any E-commerce that sells to anyone in the EU
Hardware and software products brought the market after June 2025
Computers, smart phones, ATMs television equipments, E-Readers, ticketing and check-in machines
Banking
Telecommunications
Transport services
Audio-visual media services
Exceptions
Published before June 2025
Any 3rd party content that you donât have control over
Non-Compliance
Financial and Legal penalties
B2B procurement: UPAT
Monetary fines
Reputational Damage
Compliance Standards
WCAG 2.2 Level AA
European Standard (EN 301 549)
WCAG 2.2 Updates
WCAG is a set of guidelines developed by the World Wide Web Consortium (W3C) to ensure web content is accessible to people with disabilities.
WCAG 2.2 introduced several new success criteria in October of 2023 aimed at enhancing accessibility. WCAG 2.2 added personas to the success criterion in order to better empathize with the needs of the users.
To maintain an accessible website in 2024, you need to ensure your website follows all of the WCAG 2.1 Level A & AA guidelines as well as the new WCAG 2.2 updates. These updates include:
Focus Not Obscured (Minimum) – Level AA
When a user interface receives keyboard focus the component is not hidden due to author-created content.
âThis page has a big banner thatâs always across the bottom. (a sticky footer) When I move focus to items, some are hidden behind the banner and I canât see themâ
– Persona Alex, a reporter with repetitive stress injury
Dragging Movements – Level AA
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging unless dragging is essential.
ex, a map allows users to drag the view of the map around, and the map has up/down/left/right buttons to move the view as well.
âI cannot hold down the mouse button and drag it accurately enough to move the items in the list.â
-Persona Yun, a retiree with hand tremor
Target Size (Minimum) – Level AA
The minimum size for any target should be 24px by 24px
âThe buttons are so close, I hit âCancelâ when going for âSubmitâ. Then I have to start all over again.â
– Persona Yun, a retiree with hand tremor
Consistent Help – Level A
Put help in the same place when it is on multiple pages.
âWhenever I use the online app to schedule my medical appointments, I canât remember what to do at each step. Iâve seen a chat option in some places, but canât find it nowâ
– Persona Luis, a supermarket assistant with cognitive disabilities
Redundant Entry – Level A
Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select.
âWhenever I use the online app to schedule my medical appointments, I have to re-type some information that I entered in a previous step.â
-Persona Luis, a supermarket assistant with cognitive disabilities
Accessible Authentication (minimum) – Level AA
Donât make people solve, recall, or transcribe something to log in.
âI can never remember my password, itâs really hard to get into this app.â
-Persona Luis, a supermarket assistant with cognitive disabilities
How to ensure your website is accessible
To ensure your website is accessible, follow these steps:
Conduct an Accessibility Audit: Evaluate your current website against WCAG 2.2 standards to identify areas that need improvement.You can use a scanner like RocketValidator.
Implement Necessary Changes: Make the required updates to meet accessibility guidelines. This may include adjusting contrast ratios, ensuring keyboard navigability, and providing text alternatives for non-text content.
Use Accessible Design Practices: From the start of the design process, incorporate accessible design principles to ensure all new content is compliant.
Test with Real Users: Conduct usability testing with individuals who have disabilities to get direct feedback on your websiteâs accessibility.
Keep Up with Updates: Accessibility standards and technologies evolve. Stay informed about the latest updates to WCAG and other relevant guidelines.
By proactively addressing accessibility, you not only comply with legal requirements but also create a more inclusive and user-friendly experience for all visitors to your website.Ready to make your website accessible?Contact Atlantic BT today to ensure your digital content meets the latest accessibility standards and provides a seamless experience for all users.
One of the most common types of development work done at Atlantic BT is building APIs. An API (Application Programming Interface) is a set of defined rules that allow different software applications to communicate and share data with each other. The APIs we develop at Atlantic BT are used not only by the websites we create, but by external clients and third-party services. Therefore, defining, documenting, and testing these APIs is a critical part of our process. This blog post will showcase several helpful tools that we use while building APIs for our clients.
Defining and Documenting APIs
Defining and documenting your API is an important step when building and maintaining an API. Regardless of whether the consumer of your API is an internal or external user, having a clear understanding of how to interact with your API is essential for making the development process as smooth as possible. Fortunately, there exists a suite of tools to help with this.
Swagger (referred interchangeably with Open API) is a standard, programming language independent way to describe APIs. When defining your API, you create an Open API specification that describes your API’s endpoints, input/output parameters, and authentication methods. This specification can then be used to generate interactive documentation and client SDKs.
Swashbuckle is a .NET library that automatically generates Open API standard documentation from your existing API code and provides a user-friendly UI for testing them. This is great for legacy applications that may be missing documentation. With minimal code, Swagger documentation can be generated, giving developers and API users specifications that would otherwise take considerable time to write and maintain. While Swashbuckle is a .NET specific library, there exists comparable tools made in almost every language.
SwaggerHub is a collaborative platform designed for API development that leverages the Swagger/OpenAPI standard. It provides a centralized place to manage and version your API documentation. At Atlantic BT, we use SwaggerHub when building APIs that need to be consumed by our clients. This allows everyone involved to always have the latest API definition, which makes collaboration with our clients much more efficient.
Testing APIs
Once your API has been defined, and development has started, testing that API becomes the focus to ensure it is functioning as expected. Once again, there exists a variety of tools to help with this important step.
Postman is an API testing tool that offers a user-friendly interface for making requests and viewing responses. It allows you to save and organize your requests in collections, which helps if you work on multiple APIs or work with many clients, as we do at Atlantic BT. It allows simple control over the headers and body of the request, which make it our preferred tool when we quickly need to test out an API endpoint.
One of the common scenarios that leads us to develop an API for our clients is to receive data from a webhook on a third-party site. A webhook is a method used to send notifications to other systems by making an HTTP request to a specified URL whenever a particular event occurs. When developing this webhook API endpoint, the problem is that the computer you use to do development work on often isnât publicly accessible by the site sending the API request. So how are you supposed to know what the webhook data looks like? One way to solve this problem is using Webhook.site
Webhook.site gives you a unique publicly available URL that you can have a site send requests to. In addition, it has a simple interface that allows you to view all the requests that are sent to that unique URL. You can then copy the request data that was sent and paste it into Postman running on your computer to send to your in development API.
Another solution to testing a webhook is to use ngrok. ngrok is a tool that runs on your computer and creates a secure tunnel from a public URL to your local machine. This allows you to expose and test your local API over the internet. Using ngrok will let you test the full flow of the webhook without having to use the extra steps of having data sent to Webhook.site and then sending the data again using Postman. ngrok also allows you to inspect and replay requests, which is helpful so you donât have to trigger the webhook repeatedly.
Conclusion
Whether an API is public-facing or behind the scenes, it is an integral part of modern web development. Regardless of the purpose of the API, documenting and testing are key steps in our software development process at Atlantic BT. And with the help of the above-mentioned tools, it allows us to be more detailed, rigorous, and consistent when building and maintaining APIs for our clients.
