Effective Date: September 8, 2026 Last Updated: September 8, 2026
1. Our Commitment to Accessibility
Phillforce believes powerful business intelligence should be usable by as many people as reasonably possible. Phillforce, Inc. (“Phillforce,” “we,” “our,” or “us”) is committed to improving the accessibility and usability of our websites, digital products, customer acquisition intelligence platform, authentication experiences, reports, communications, and other customer-facing digital services. Accessibility is not something we view as a one-time website project. It is an ongoing part of how we design, build, test, improve, and operate Phillforce. We want customers, visitors, founders, professionals, team members, and other users with disabilities to be able to understand our content, navigate our interfaces, interact with our services, and access the information they need.
2. Who We Are
Phillforce is operated by: Phillforce, Inc. 8 Wading Bird Loop Blythewood, SC 29016 United States Website: phillforce.com Accessibility enquiries: accessibility@phillforce.com General enquiries: philip@phillforce.com
3. Scope of This Accessibility Policy
This Policy applies, where reasonably applicable, to customer-facing digital experiences operated by Phillforce, including:
- phillforce.com;
- Phillforce Intelligence;
- account registration and authentication;
- login and account-management experiences;
- Ask Phill;
- dashboards;
- acquisition analyses;
- diagnostic reports;
- data visualizations;
- forms;
- customer support interfaces;
- public policy pages;
- digital documents;
- downloadable reports;
- marketing pages;
- and other digital products or services that link to this Policy.
Some third-party technologies, embedded services, or externally operated platforms may be governed by their own accessibility practices. We discuss those situations later in this Policy.
4. Our Accessibility Standard
Phillforce uses recognized accessibility principles and technical standards to guide our accessibility work. Our accessibility objective is to work toward substantial conformance with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, where reasonably applicable to our websites and web applications. WCAG is an internationally recognized accessibility standard developed by the World Wide Web Consortium. WCAG is organized around four broad principles:
- content should be perceivable;
- interfaces should be operable;
- information and interactions should be understandable; and
- technology should be sufficiently robust to work with appropriate user agents and assistive technologies.
Phillforce may also consider applicable accessibility laws, regulations, standards, and recognized best practices in jurisdictions where our Services are offered. Our use of WCAG as an accessibility objective does not mean that every Phillforce page, feature, document, or third-party component will necessarily satisfy every success criterion at every moment. Accessibility is an ongoing process, particularly as Phillforce continues to develop new functionality.
5. United States Accessibility
Phillforce, Inc. is a United States company. We seek to operate our customer-facing digital services consistently with applicable United States accessibility obligations, including requirements that may apply under the Americans with Disabilities Act and other applicable federal, state, or local laws. Where a particular legal requirement applies to Phillforce, we intend to address that requirement appropriately. We also use recognized technical accessibility guidance, including WCAG, to inform our design and development practices.
6. International Accessibility
Phillforce serves a global audience. Accessibility requirements may differ across countries and regions. Depending on the nature of our Services and the users we serve, accessibility requirements or standards may arise under laws and frameworks in jurisdictions including the European Union, United Kingdom, Canada, Australia, and other countries. Where an applicable accessibility law imposes requirements on Phillforce, we intend to address those requirements as appropriate. Phillforce's use of recognized international accessibility principles is intended to create a stronger and more consistent experience across jurisdictions rather than designing accessibility solely around one country.
7. Accessibility and the Phillforce Design Philosophy
Phillforce is intentionally a visual and analytical product. Our dashboards may contain:
- charts;
- graphs;
- funnel visualizations;
- system-health displays;
- scoring interfaces;
- priority matrices;
- evidence indicators;
- confidence displays;
- constraint maps;
- modeled commercial scenarios;
- interactive cards;
- animations;
- analytical diagrams.
We do not believe accessibility requires Phillforce to abandon its premium visual identity or analytical experience. Instead, our goal is to make important information available through accessible structure, labels, text, interaction patterns, and alternatives where reasonably appropriate. Our design principle is: Preserve the intelligence. Preserve the premium experience. Improve the ways people can access it.
8. Visual Analytics and Data Visualization
Because visual analysis is central to Phillforce, we pay particular attention to how analytical information is communicated. Where reasonably practicable, important information presented through charts, graphs, diagrams, or other visualizations should not depend exclusively on visual perception. Phillforce may provide supporting information through methods such as:
- meaningful chart titles;
- descriptive labels;
- accessible names;
- explanatory text;
- summaries;
- visible values;
- data tables where appropriate;
- keyboard-accessible controls;
- contextual explanations;
- Ask Phill explanations;
- downloadable reports;
- alternative representations of important analytical information.
For example, if a funnel chart indicates that one stage has the lowest reported conversion rate, the important conclusion should also be available in readable text rather than existing only as the relative size or color of a graphical element.
9. Color and Contrast
Phillforce uses a distinctive visual identity, including dark interfaces, light interfaces, and brand accent colors. We aim to maintain sufficient contrast between important text, controls, backgrounds, and interactive elements. Color should not be the only way important information is communicated. Where color communicates status, priority, warning, success, confidence, or another meaningful distinction, Phillforce should also use an additional indicator where reasonably appropriate. This may include:
- text;
- labels;
- icons;
- patterns;
- values;
- headings;
- accessible names.
For example, a finding should not be communicated as “high priority” solely because it appears in a particular color.
10. Keyboard Accessibility
We aim to make important interactive functionality operable using a keyboard where reasonably applicable. This includes attention to elements such as:
- navigation;
- links;
- buttons;
- menus;
- dialogs;
- forms;
- account controls;
- filters;
- settings;
- authentication;
- analytical controls;
- and other interactive components.
Keyboard users should be able to identify where focus is located. Phillforce should avoid intentionally removing visible focus indicators without providing an accessible replacement.
11. Focus Management
Interactive experiences should provide logical and predictable focus behavior where reasonably practicable. This is particularly important for:
- modal dialogs;
- mobile navigation;
- dropdown menus;
- authentication flows;
- confirmation dialogs;
- account deletion;
- error messages;
- dynamically updated interfaces.
When a dialog opens, focus should generally move in a useful way. When it closes, focus should generally return to a logical location. We seek to avoid interfaces where keyboard focus becomes hidden, trapped incorrectly, or lost.
12. Screen Reader Compatibility
Phillforce aims to use semantic structure and appropriate accessibility information so that important content and functionality can be interpreted by commonly used assistive technologies. Our development practices may include attention to:
- semantic HTML;
- meaningful headings;
- form labels;
- accessible names;
- landmarks;
- link purpose;
- button purpose;
- status messages;
- alternative text;
- table structure;
- ARIA attributes where appropriate;
- dynamic content announcements where necessary.
ARIA or similar accessibility attributes should be used to improve accessibility, not as a substitute for appropriate semantic HTML where native elements are available.
13. Images and Alternative Text
Informative images should have meaningful alternative text or an appropriate equivalent where reasonably practicable. Decorative images may use empty alternative text or another method that allows assistive technologies to ignore them. Alternative text should communicate the purpose or important information conveyed by an image rather than mechanically describing every visual detail. Complex charts or diagrams may require more extensive accompanying explanations than ordinary images.
14. Forms
Forms are an important part of Phillforce. These may include:
- account registration;
- login;
- password reset;
- Company Evidence;
- contact forms;
- checkout;
- customer intake;
- privacy requests;
- account settings.
We aim for forms to include appropriately associated labels, instructions, validation, and error information. Where possible, users should be told:
- what information is required;
- what went wrong;
- where the error occurred;
- and what they can do to correct it.
Important instructions should not depend solely on placeholder text inside an input field.
15. Authentication Accessibility
Access to a user's account is a fundamental part of Phillforce. We therefore seek to design authentication experiences that are reasonably accessible. Our authentication environment may include:
- email and password;
- Google authentication;
- LinkedIn authentication;
- password reset;
- email verification;
- account recovery;
- security confirmations.
Where reasonably practicable, authentication should not unnecessarily require a person to perform cognitive tasks that create avoidable accessibility barriers where an accessible alternative can be provided. We also aim to support password managers, browser autofill, copy and paste, and other accessibility-supporting authentication functionality where compatible with appropriate security requirements.
16. Profile and Account Management
Where Phillforce allows users to manage account information, we seek to make important settings accessible. These may include:
- changing a name;
- changing a profile photograph;
- updating an email address;
- managing authentication methods;
- changing a password;
- managing sessions;
- updating preferences;
- logging out;
- deleting an account.
Accessibility should be considered when new account controls are introduced.
17. Navigation
Phillforce aims to provide navigation that is understandable and reasonably consistent. We seek to use:
- meaningful navigation labels;
- predictable placement;
- clear headings;
- sensible information hierarchy;
- accessible mobile navigation;
- distinguishable current-page states where appropriate.
As Phillforce grows, we may use grouping, progressive disclosure, collapsed navigation, or other interface patterns to keep complex product navigation manageable. Those patterns should be implemented with accessibility in mind.
18. Headings and Page Structure
Pages should use meaningful structural organization where reasonably practicable. Headings should help users understand how information is organized rather than being selected solely because of visual appearance. We seek to avoid using heading elements purely for styling while ignoring the logical structure of the page. This is especially important for long pages such as:
- Privacy Policy;
- Terms of Service;
- Cookie Policy;
- reports;
- case studies;
- analytical explanations;
- resources.
19. Links and Buttons
Links and buttons should communicate their purpose where reasonably possible. We seek to avoid ambiguous controls where context does not make the action understandable. Interactive elements should also be distinguishable from ordinary text through appropriate visual and structural cues. Where an icon-only control is used, an accessible name should be provided where appropriate.
20. Text Resizing, Zoom, and Responsive Design
Phillforce is designed for use across different screen sizes and devices. We seek to support browser zoom, text resizing, and responsive layouts without unnecessarily preventing access to important content or functionality. Users should generally be able to zoom or enlarge content using browser or operating-system capabilities. Our responsive design work includes consideration of:
- desktop computers;
- laptops;
- tablets;
- mobile devices;
- landscape and portrait orientation where appropriate.
21. Motion and Animation
Animation is part of the premium Phillforce experience. We do not intend to remove useful animation merely because accessibility is important. Instead, we aim to use motion responsibly. Where animation or movement could create significant accessibility barriers, we may consider:
- reduced-motion preferences;
- less intensive alternatives;
- controls;
- avoiding unnecessary flashing;
- avoiding excessive movement;
- preventing motion from blocking access to content.
Where technically practical, Phillforce should respect relevant operating-system or browser reduced-motion preferences.
22. Flashing Content
Phillforce does not intentionally design customer-facing interfaces around rapidly flashing content. We seek to avoid visual effects known to create unnecessary seizure or photosensitivity risks. Animations, transitions, charts, loading states, and promotional elements should be designed with this consideration in mind.
23. Video and Audio
Where Phillforce publishes meaningful prerecorded video or audio content, we will consider appropriate accessibility features based on the nature of the content. These may include:
- captions;
- transcripts;
- audio descriptions where appropriate;
- accessible media controls;
- descriptive supporting text.
Not every decorative or redundant media element will necessarily require every accessibility alternative. Our objective is to ensure that important information is reasonably available to users who cannot access the original audio or visual format.
24. Live Events, Webinars, and Demonstrations
Phillforce may conduct demonstrations, webinars, customer calls, training, or other live digital experiences. Where reasonably possible and appropriate to the event, we may consider accessibility needs including:
- captions;
- transcripts;
- accessible presentation materials;
- alternative ways to submit questions;
- advance requests for accommodations.
If you require an accessibility accommodation for a Phillforce-hosted event, please contact us as early as reasonably possible.
25. Downloadable Documents and Reports
Phillforce may generate or distribute:
- PDF reports;
- commercial intelligence reports;
- proposals;
- policy documents;
- case studies;
- presentations;
- downloadable resources.
We aim to improve the accessibility of important documents over time. Where a document is not reasonably accessible to you, you may contact Phillforce to request the information in an alternative accessible format where reasonably possible.
26. Ask Phill as an Accessibility Support Layer
Ask Phill may also help users interpret complicated acquisition intelligence through conversational interaction. For example, a user who finds a complex chart difficult to interpret may be able to ask Ask Phill to explain the relevant finding in text. Ask Phill is not a replacement for accessible interface design. It may, however, provide an additional way of interacting with and understanding Phillforce intelligence. Because Ask Phill is AI-enabled, its explanations may occasionally contain errors and should be considered together with the underlying evidence and analysis.
27. Error Messages and Status Information
Phillforce contains dynamic processes such as:
- running diagnoses;
- uploading information;
- saving evidence;
- authentication;
- generating reports;
- background jobs.
Where reasonably practicable, important status information should be communicated clearly. Users should not be required to infer a critical error solely from a color change or visual animation. Important failures should provide understandable information about what happened and, where possible, what the user can do next.
28. Time Limits
Where Phillforce introduces time-limited interactions, we will consider whether users require reasonable warning, extension, adjustment, or another accessible approach. Security-related session expiration may still be necessary to protect accounts. Our goal is to balance accessibility with legitimate security requirements.
29. Language and Readability
Phillforce serves a global professional audience. We aim to use clear, understandable language where appropriate, particularly for:
- navigation;
- forms;
- authentication;
- privacy information;
- account settings;
- security notices;
- error messages;
- customer instructions.
Technical or commercial terminology may still be necessary in customer acquisition analysis. Where appropriate, Phillforce may provide explanations or contextual descriptions to help users understand specialized terminology.
30. Premium Design and Accessibility
Accessibility improvements should not be used as a reason to unnecessarily reduce the quality of Phillforce's visual design. Phillforce's design team and developers should seek solutions that preserve:
- premium typography;
- visual hierarchy;
- dashboards;
- analytical charts;
- animations;
- card systems;
- brand colors;
- spacing;
- interaction quality;
- product personality;
while improving access for people with disabilities. The objective is not to choose between premium design and accessibility. The objective is to build a premium product that takes accessibility seriously.
31. Third-Party Services
Phillforce may integrate with or link to third-party products and services. Examples may include:
- Google;
- LinkedIn;
- payment processors;
- video providers;
- scheduling services;
- analytics platforms;
- social platforms;
- embedded media;
- customer-support technologies.
Phillforce does not control every accessibility feature of independently operated third-party services. We encourage third-party vendors to provide accessible experiences and may consider accessibility when selecting or reviewing important vendors. However, accessibility issues within a third party's independently controlled product may need to be addressed by that provider.
32. Vendor and Procurement Considerations
As Phillforce grows, accessibility may be considered when evaluating significant vendors and technologies that materially affect the customer experience. Where appropriate, we may consider:
- accessibility documentation;
- known compatibility limitations;
- accessibility conformance reports;
- vendor commitments;
- available alternatives;
- remediation processes.
Accessibility may be one factor among security, privacy, functionality, reliability, cost, and other legitimate procurement considerations.
33. Development Practices
Phillforce may incorporate accessibility considerations into its software development process. Depending on the feature, this may include:
- semantic markup;
- keyboard testing;
- contrast evaluation;
- responsive testing;
- screen-reader testing;
- focus testing;
- form testing;
- zoom testing;
- automated accessibility testing;
- manual review;
- visual regression testing;
- accessibility review of major new components.
Automated testing alone cannot identify every accessibility problem. Where appropriate, accessibility review should combine automated and human evaluation.
34. AI-Assisted Development
Phillforce may use artificial intelligence to assist with software development. AI-generated code is not automatically assumed to be accessible simply because it functions visually. Accessibility requirements should remain part of review and quality assurance for AI-assisted development. Developers working on Phillforce should avoid introducing inaccessible implementations merely because they are faster or easier to generate. The expected workflow is: Build → Test → Review accessibility → Correct → Validate → Release
35. New Features
Accessibility should be considered when Phillforce introduces significant new customer-facing functionality. This may include:
- new dashboards;
- new charts;
- new authentication methods;
- Connected Intelligence;
- team workspaces;
- new forms;
- new navigation;
- new reporting;
- new AI functionality.
We may prioritize remediation based on:
- severity;
- customer impact;
- frequency of use;
- availability of alternatives;
- technical complexity;
- legal requirements;
- security considerations.
36. Accessibility Testing
Phillforce may periodically evaluate accessibility through a combination of methods. These may include:
- automated accessibility testing tools;
- keyboard-only navigation;
- screen-reader testing;
- contrast testing;
- zoom and responsive testing;
- manual interface review;
- user feedback;
- code review.
Testing may focus first on important user journeys such as: Home → Run Free Intelligence → Create Account → Complete Evidence → View Diagnosis → Use Ask Phill → Manage Account.
37. Accessibility Is an Ongoing Process
Digital accessibility is not something we consider permanently “finished.” Phillforce's products, interfaces, technologies, browsers, devices, standards, and customer needs will continue to change. We may therefore identify accessibility issues after a feature has already been released. When we become aware of a meaningful accessibility barrier, we intend to assess it and make reasonable efforts to improve the experience based on factors including severity, impact, technical feasibility, available alternatives, and applicable law.
38. Known Limitations
Despite our efforts, some parts of Phillforce may not always be fully accessible. Possible limitations may involve:
- newly released functionality;
- experimental features;
- highly complex data visualizations;
- legacy content;
- third-party integrations;
- embedded media;
- externally generated documents;
- temporary technical issues.
The presence of a limitation does not mean accessibility is unimportant to us. We encourage users to report barriers so that we can better understand and prioritize them.
39. Alternative Access
If you cannot access important Phillforce information or functionality because of an accessibility barrier, contact us. Where reasonably possible, we will attempt to provide an alternative way to access the relevant information or service while the underlying issue is being assessed. Depending on the request, this may include:
- information in a different format;
- support assistance;
- a text explanation;
- an accessible copy of a document;
- another reasonable alternative.
40. Requesting an Accessibility Accommodation
If you need a reasonable accessibility accommodation in connection with a Phillforce service, event, document, or customer interaction, you may contact: accessibility@phillforce.com Please tell us:
- what you were trying to access;
- where you encountered the issue;
- what barrier you experienced;
- and, if you wish, what type of accommodation would help.
You do not need to provide unnecessary medical information to report an accessibility problem.
41. Reporting an Accessibility Issue
We welcome accessibility feedback. When reporting a problem, helpful information may include:
- the page or feature involved;
- the device being used;
- the browser;
- the assistive technology, if relevant;
- a description of what happened;
- what you expected to happen.
Please do not include passwords, authentication credentials, sensitive personal records, or unnecessary confidential information in an accessibility report.
42. Our Response to Accessibility Feedback
When Phillforce receives a meaningful accessibility report, we may:
- acknowledge the issue;
- investigate it;
- attempt to reproduce it;
- assess severity and impact;
- identify a temporary alternative where appropriate;
- prioritize remediation;
- communicate additional information where reasonably possible.
Resolution times may vary depending on the nature and complexity of the issue. We do not want to promise an artificial deadline that may not be appropriate for every accessibility issue. Our objective is to address meaningful barriers responsibly and within a reasonable timeframe.
43. No Retaliation for Accessibility Requests
Phillforce will not intentionally deny a user ordinary access to the Services merely because that person reports an accessibility barrier or requests a reasonable accommodation. Accessibility feedback is valuable information that can help us improve the product.
44. Accessibility and Security
Accessibility and security are both important. There may occasionally be situations where an accessibility feature or requested alternative must be implemented in a way that preserves legitimate security controls. For example, Phillforce may require identity verification before allowing access to sensitive account information. Where accessibility and security requirements interact, our goal is to find a reasonable approach that preserves both wherever practicable.
45. Accessibility and Privacy
You do not need to disclose a diagnosis or detailed medical history simply to report that an interface is inaccessible. Accessibility requests may involve personal information, and Phillforce will process such information according to our Privacy Policy and applicable law. We encourage users to provide only the information reasonably necessary for us to understand and address the request.
46. Changes to This Accessibility Policy
Phillforce may update this Accessibility Policy as:
- our products evolve;
- accessibility standards change;
- applicable laws change;
- accessibility practices improve;
- new technologies are introduced;
- customer feedback identifies new needs.
The “Last Updated” date at the beginning of this Policy will indicate the most recent revision. Material changes may also be communicated through another appropriate method where necessary.
47. Contact Phillforce
Questions, accessibility feedback, or accommodation requests may be directed to: Phillforce, Inc. 8 Wading Bird Loop Blythewood, SC 29016 United States Accessibility: accessibility@phillforce.com General enquiries: philip@phillforce.com Privacy: privacy@phillforce.com Website: phillforce.com
Phillforce, Inc. Clarity before activity.
End of Accessibility Policy
