Accessibility is a foundational requirement for any organization that wants to build inclusive, effective and future-ready experiences. At Brightspot, accessibility is built into the platform, championed by every contributor to the digital process — designers, developers, content creators and product managers alike.
Here’s how Brightspot embeds accessibility into its CMS platform and delivery processes, with perspectives from the people leading this important work.
Built for real-world use
“Just because a site looks good doesn’t mean it works for everyone,” says Basima Zafar, a developer at Brightspot. Her personal connection to accessibility brings unique insight. Her mother, who is blind, uses the JAWS screen reader to navigate websites. The experience is entirely linear; no skimming or scanning, just one element at a time, in the order the code provides.
What’s just a mild inconvenience for a sighted user becomes a full barrier for blind users.
“If a site is well-structured, she can skip menus and jump straight to what she needs,” Basima explains. “But if that structure is missing, it becomes a long and frustrating maze.”
She emphasizes the importance of properly labeled headings, links and buttons. Without them, even routine tasks like booking an appointment or submitting a form become inaccessible. “Shortcut keys aren’t just conveniences. They’re lifelines.”
Digital accessibility refers to making sure that all people, including those with disabilities, can easily access and use digital content. That includes websites, apps and all other online tools. The goal is to make sure no one is excluded from accessing important online resources, regardless of their physical, cognitive or sensory abilities.
Barriers to access can be permanent, temporary or contextual.
WCAG (Web Content Accessibility Guidelines) standards can be broken into:
- Perceivable: Information must be perceivable to people using only one of their senses, so they understand all related content.
- Operable: End users must be able to interact with all webpage elements. For instance, your website should be easily navigable with just a keyboard or voice controls for non-mouse users.
- Understandable: The principle is just what it seems — end users must be able to understand web page content and functionality information.
- Robust: Your website must effectively communicate information to all users, including users of assistive technologies, and remain compatible with evolving technologies and user needs.
Everyone deserves equitable access to information, communication, and opportunity. Implementing accessibility benefits us all — not just users with disabilities:
- Inclusive design: Expands user base and customer satisfaction.
- Legal Compliance: Avoids lawsuits and fines (U.S. ADA Title II, European Accessibility Act).
- SEO & visibility: Improves search engine rankings and discoverability.
- Financial opportunity: People with disabilities represent over $1 trillion dollars in spending power in the U.S. alone.
- Business growth: Companies see higher engagement, loyalty and revenue from accessible platforms.
- Ethical responsibility: Equitable access for all creates a more inclusive society.
The Web Content Accessibility Guidelines (WCAG) are a set of guidelines developed by the World Wide Web Consortium (W3C) to make web content more accessible to people with disabilities. These guidelines cover a wide range of recommendations for making web content more accessible.
WCAG’s 2.1 AA level of compliance is considered the industry standard, addressing most critical accessibility issues for people with vision, hearing, motor or cognitive disabilities. For digital buyers and developers alike, this should be your team’s default accessibility target moving forward.
While WCAG itself is not a federal law in the U.S., its guidelines are often referenced in legal contexts. Section 508 of the Rehabilitation Act requires federal agencies to make their electronic and information technology accessible to people with disabilities. Non-compliance with WCAG can lead to penalties under this section.
Beyond legal exposure, accessibility failures come at the cost of usability, reputation and market reach. An estimated 1.3 billion people — roughly one in six worldwide — live with a disability. In the U.S. alone, the disabled population represents more than $1 trillion in annual disposable income.
On June 28, 2025, all new digital products and services targeting users in the European Union were required to meet accessibility requirements under the European Accessibility Act (EAA).
The WCAG 2.1 AA standard is the baseline for the EAA, but individual countries may impose different requirements and remedies, which means it could become stricter and entail different sanctions on a country-by-country basis.
Learn more here -> The European Accessibility Act deadline is coming: What digital teams need to know
Yes, Brightspot CMS meets WCAG 2.1 AA standards. Read the latest Brightspot CMS accessibility conformance report here.
Design that works for everyone
Good accessibility starts with good design. For Brightspot’s director of design services, Mike Wang, that means thinking beyond visuals.
“Good design is open for everybody,” Wang says. “We primarily focus on color and contrast, but other important aspects like typography and responsive layouts are built in the fabric of our design system.”
Core design principles include:
- Prioritizing color contrast
- Using readable typography and responsive layouts
- Structuring content with clear heading hierarchies
- Enforcing consistent spacing, labeling and patterns
“We use 720 pixels as the standard article width to reduce eye fatigue. Even our CTA buttons follow consistent formats like ‘Read the case study’ or ‘View pricing options.’ That kind of specificity is critical for both usability and screen readers.”
Motion is another consideration. While animations and transitions can enhance visual appeal, they can overwhelm some users. Wang and his team of experts are exploring ways to give users control over motion effects, including optional toggle features.
Development grounded in semantics
The structure of the page matters as much as the content. Front-end developer Andres Gallo stresses the importance of semantic HTML, proper heading hierarchy and logical reading order.
Not a single line of code should be written before asking: how will this structure help or hurt accessibility?
“We ask questions before we write a single line of code,” he says. “What’s the main title? Is it part of the page or just a module heading? That determines whether we use an H1, H2 or H3.”
Gallo shares examples of nested modules where flat heading structures pass automated scans but confuse screen readers. Brightspot has since adopted dynamic heading levels to preserve hierarchy and improve clarity for assistive technology users.
Landmarks such as headers, footers and navigation regions also help users understand where they are on the page. “It’s not just about passing tests. It’s about building markup that creates a clear experience for everyone,” Gallo says.
Enabling accessible publishing
While developers and designers lay the groundwork, accessibility also depends on how content is published.
“We give content creators tools to enter alt text, but if that step is skipped, the system defaults to the image file name,” says Basima Zafar. “And screen readers ignore file names. It’s not a technical flaw. It’s a publishing habit that needs to change.”
Accessibility isn’t just about how we build sites — it’s also about how we support and train content creators to publish accessibly.
Link labels are another common challenge. QA specialist Grace Owolabi explains why vague CTAs like “Learn more” or “Click here” fall short. “They don’t tell screen reader users what the link is about. Instead, use something like ‘Learn more about 2025 scholarship deadlines.’ That gives real context.”
Forms need attention, too. Standard HTML elements like and help screen readers associate inputs with their instructions. “It’s not about reinventing the wheel,” Gallo says. “It’s about using the right tools the right way.”
Testing beyond the checklist
Brightspot’s QA team integrates accessibility testing into every stage of the development process. Automated tools like Axe and Lighthouse are just the beginning.
“Automated scans are important, but they only catch a portion of the issues,” says Rebecca Grad, who leads QA accessibility testing at Brightspot. “Manual testing is non-negotiable.”
The team conducts keyboard-only navigation, zooms up to 300 percent and tests with screen readers like VoiceOver and NVDA. “We check for focus traps, missing alt attributes, unlabeled buttons — anything that could disrupt the experience for a real user.”
Brightspot also conducts regular audits of its own CMS platform, testing both light and dark modes, reviewing templates and expanding its automated toolset to scan full sites.
“Fixing issues in development is dramatically less costly than correcting them in production,” Grad notes. “But it’s not just about cost. It’s about doing right by all users.”
Our approach to accessibility comprises a mix of automated and manual testing. For automated testing, some tools we use include:
- Google Lighthouse: Lighthouse is a free tool provided by Google. During a test we audit things like: color contrast, presence of alt attributes on images, proper use of ARIA roles, tabindex usage
- Axe Pro: This tool allows us to conduct an automated check against a larger sampling size of project URLs and reports on different levels of accessibility standards and best practices. We can also use Axe to test against different device types.
- Keyboard navigation
- Screen reader compatibility
- Color contrast
- Image alt text
- Form accessibility
Using the feedback from the above manual tests, the engineer is able to go in and evaluate the types of issues reported as well as ensure everything looks good from a user standpoint.
Interested to learn more about our accessibility testing tools and approach? Get in touch with us here.
Accessibility built into the platform
Brightspot’s CMS is designed to help teams meet and maintain accessibility standards — without requiring them to be experts.
Kate Westman, who helps oversee the platform experience, explains how lessons learned from accessibility-intensive projects lead to repeatable improvements. “We’ve documented code patterns, ARIA usage guidelines and semantic HTML practices to make it easier for teams to get this right the first time.”
Built-in support includes:
- Semantic HTML elements and headings
- Alt text prompts and fallbacks
- Screen reader-friendly focus states
- Templates with accessibility baked in
Even non-developers can use browser tools and built-in OS features to test basic accessibility. “It’s not about perfection,” Westman says. “It’s about making steady progress and catching the obvious issues before they reach end users.”
Process and planning
For Brightspot’s product and engineering teams, accessibility is part of every project conversation. Product manager Olivia Grocock emphasizes the importance of starting early — especially with new implementations.
“We talk about accessibility during project kickoff. We embed it in design reviews, user stories and QA checklists,” she says. “Waiting until the final sprint to run an accessibility test is too late.”
Brightspot also supports ongoing accessibility efforts for existing sites. “We’re developing repeatable ways to estimate, scope and prioritize accessibility work. Even if a project is live, it’s never too late to make it better.”
And it’s not just our customers’ websites. Accessibility is an intrinsic part of how we develop our CMS platform to be compliant based on the latest Web Content Accessibility Guidelines (WCAG). As with a front-end site, things like field-level tabbing, labeling and different screen modes for color contrast in the CMS are all developed — and thoroughly tested — with accessibility in mind.
A shared responsibility
At Brightspot, accessibility is a team sport. From strategy to launch, everyone contributes to making the web more inclusive.
“None of us are full-time accessibility experts, and that’s OK,” says Rebecca Grad. “But we all have a role to play.”
Whether you’re writing requirements, designing modules, authoring content or testing releases, accessibility should be part of the conversation from the beginning. Brightspot’s approach ensures it’s not just a checkbox at the end of a project but a guiding principle from the start.
Why accessibility matters
The web should work for everyone. Brightspot is committed to building digital experiences that are inclusive, usable and accessible by default. That commitment is reflected in the CMS, in how projects are delivered and in how teams are supported every step of the way.
Because accessible design isn’t just good for some users, it’s better for all.
