How to Create a Product-Accessibility Support Case

Clarivate is committed to ensuring accessibility in our products through integration during design and development, by conducting annual internal and third-party audits, and by responding to user-submitted cases. To enable us to provide an efficient response, please review the guidelines for submitting an accessibility support case, below.

Our Commitment to Accessibility

Clarivate strives for conformance with WCAG 2.2 AA in our Academia & Government products. When reporting accessibility issues, to facilitate an efficient turn-around on requests, please provide detailed and specific information. If you are planning to submit an accessibility audit of more than ten issues, please refer to the Audit Process Guidelines section, below, for more information.

Our goal is to achieve conformance with WCAG 2.2 AA across all of our current products. Due to technical constraints or legacy architecture, some products may be working towards WCAG 2.1 at this time. For these cases, we are prioritizing updates based on usage and feasibility.

Support Case Guidelines

Please include the following in your support case:

1. Enter a concise Subject and detailed Description of the issue.
2. Under Case Type, select Accessibility (Assistive Technology).

   

3. Under Priority, select the impact of the issue

   

   Case Priority	Description
   High	Blocking issue, user cannot complete task
   Medium	Difficult to finish a task, but not impossible
   Low	Limited end-user impact that may still be a technical failure under WCAG

4. Provide written steps to replicate as a user along with the actual and expected results. For example:
   1. Login as Test User
   2. Navigate to Virtual Browse
   3. Action the carousel scroll button with a keyboard
   4. Actual result: Keyboard navigation gets lost trying to reach scroll button, only actions on mouse click
   5. Expected result: Carousel scroll can be navigated to and actioned via keyboard
5. Specify the screen reader used and version (if keyboard only, please identify).
6. Indicate which WCAG 2.2 AA success criteria are violated (as applicable and/or known).
7. Attach a screen recording with audio or screen shot(s) of the issue.
   • If a screen recording is possible, please capture the interaction prior to the issue, the issue itself, and the interaction following. Please include audio describing the actual and expected behavior.

Customizations

Accessibility issues introduced due to customizations may fall outside the scope of our support. If you are unsure whether an issue is related to the core product or a customization, please submit a case with the details provided above and we will review.

Known Issues

If an issue aligns with a known limitation documented in a VPAT or accessibility conformance report or roadmap, there is no need to resubmit it. These items are tracked and prioritized internally. If you’re experiencing a significant user impact related to a known issue, please submit with added context so we can better understand its severity or identify potential workarounds.

Audit Process Guidelines

Most of our products are audited on an annual basis, either internally at Clarivate, or by an external third-party accessibility vendor. Please review our Accessibility Conformance Reports (ACR), also often referred to as Voluntary Product Accessibility Templates (VPAT), to identify the level of accessibility the product has achieved and areas of known issues. These are important to review before submitting your results. If a product is missing from the list, please reach out to accessibility@clarivate.com.

If you are planning to submit an accessibility audit containing more than issues, please send it directly to accessibility@clarivate.com. Our Accessibility Team will work with individual products to review issues and provide a response as a remediation plan. Audit submissions that consist solely of automated testing results – without accompanying manual verification or user-impact context – cannot be accepted.

When providing your findings, please include the following:

• A severity level based on user impact such as critical, high, medium, or low
• A screenshot or link to where the issue occurs so that it can be reviewed accurately

Automated Testing Tool Guidelines

Automated accessibility tools can be a helpful starting point for identifying issues. However, they often produce false positives or flag elements that do not significantly affect the user experience, are expected behavior, or were created as a deliberate workaround. To ensure reports are actionable and accurately reflect real barriers, all accessibility issues must be manually verified – particularly using screen readers and keyboard navigation.

To assist effectively, we require clear, manual steps that will lead directly to the affected interface component. Submissions based solely on automated scan results – without accompanying manual context – cannot be addressed. Once you have confirmed that issues can be reproduced manually, please submit each verified issue as a separate support case. Reports should reflect the experience of a user encountering the issue, rather than the output from testing tools.

Example of actionable issues:

• Inability to navigate to interactive elements using a keyboard
• Keyboard traps that prevent users from moving away from an element
• Using NVDA, a screen-reader user activates a modal, but focus remains on the background content, causing them to continue to navigate behind the modal instead of within it.