- 01Premier designs toward WCAG 2.2 Level AA as the accessibility target for customer-facing web experiences.
- 02Keyboard access, readable focus states, semantic structure, contrast and reduced motion are treated as core interface concerns.
- 03We avoid claiming a formal accessibility certification that has not been independently published.
- 04If a barrier prevents you from completing a task, contact Premier and we will work with you on a practical alternative while the issue is reviewed.
This summary is for orientation. The complete sections below govern where they contain additional detail.
Our accessibility goal
Premier aims to make the marketing site and product usable by as many people as reasonably possible, including people who rely on keyboards, screen readers, zoom, high-contrast settings, reduced motion or other assistive technologies.
Our design target is the Web Content Accessibility Guidelines, WCAG 2.2, at Level AA. This is a product and design target rather than a claim that every screen has been independently certified.
Keyboard use and focus
Primary navigation, forms, dialogs and common actions should be reachable without requiring a mouse. Interactive elements should expose a visible focus state and follow a reading order that matches the structure of the page.
Where a keyboard flow is not working as expected, please report the specific page and action so Premier can reproduce the problem rather than treating it as a generic browser issue.
Semantic structure and screen readers
Premier uses semantic HTML and accessible names where practical so headings, landmarks, buttons, forms and status information can be interpreted by assistive technology.
Custom interface patterns should use ARIA only where native HTML does not already provide the required semantics. Product work should also avoid relying on icon shape alone where a text label or accessible name is needed.
Color, contrast and meaning
Text and controls are designed with contrast in mind, and important meaning should not depend on color alone. Status, validation and workflow state should also be communicated through text, labels, shape or another non-color signal where reasonably possible.
If a particular combination is difficult to read in your browser, device or display mode, include that information in your report so the issue can be evaluated in context.
Motion and animation
Premier uses motion to support orientation and state changes rather than as a requirement for understanding the page. Non-essential animation should be reduced or removed when the operating system signals a preference for reduced motion.
Content should not require a user to track fast movement, flashing elements or auto-playing visual changes in order to complete an ordinary task.
Zoom, text resizing and responsive layouts
Layouts are intended to remain usable across common mobile, tablet and desktop widths and when users increase browser zoom or text size. Content should reflow rather than forcing unnecessary horizontal navigation for ordinary reading and form completion.
Dense tables and reporting views can be more challenging on narrow screens, so those areas are treated differently from ordinary page content and should provide a practical way to inspect the underlying information.
Forms, labels and errors
Inputs should have meaningful labels and instructions that remain understandable after a user begins typing. Placeholder text may be used as a hint, but it should not be the only source of the field's meaning.
Validation messages should explain what needs attention in words and should be associated with the relevant control where practical, rather than communicating failure only through a border color or icon.
Documents and exported content
Accessibility of documents can depend on the source content, file format and export path. Premier aims to avoid creating unnecessary barriers in generated or downloadable content, but customers should review documents they create or upload if those documents will be distributed to people who rely on document accessibility features.
Third-party content and integrations
Some workflows may connect to or display content provided by third-party services. Premier cannot control the accessibility of an external site or product that a customer chooses to connect, but we welcome reports where Premier's part of the integration creates an avoidable barrier.
Testing and continuous improvement
Accessibility is considered during design and implementation through code review, keyboard checks, responsive testing and accessibility tooling where appropriate. We also use real user feedback to identify issues that automated checks can miss.
Because the product changes over time, accessibility work is treated as an ongoing part of product quality rather than a one-time completion date.
Known limitations
Complex data-heavy interfaces such as wide reporting tables, dense dashboards or large customer records can present more accessibility challenges than simple forms and pages. Premier continues to improve these areas as the product evolves.
Rather than listing a limitation that may quickly become outdated, we encourage users to report the exact workflow that is difficult so Premier can confirm the current behavior and prioritize a practical fix.
Requesting help or reporting a barrier
Email legal@premiergm.com with the page or product area, what you were trying to do, what happened and, if you are comfortable sharing it, the browser, device or assistive technology involved.
If an accessibility issue blocks an important task, say that clearly in the message. Premier will work with you on a reasonable alternative route where available while the underlying issue is reviewed.
Company contact
Accessibility questions may be sent to Premier Global Management, LLC at legal@premiergm.com. Company address: 16192 Coastal Highway, Lewes, DE 19958, United States.