Accessibility checklist for question content

Your candidate takes the test on an interface that substantially conforms to WCAG 2.2 Level AA. The question you write inside it is yours, and whether a candidate can read and answer it depends on how you write it. On HackerEarth, you write a question under Assessments by opening a test, going to the Questions tab, and selecting Create a new question. The checks below apply to what you put in the Problem name and Problem statement before you publish.

Text and language

• Write in plain, direct language. Short sentences and common words help every candidate, including those reading in a second language or under time pressure.
• Do not point to something by color, shape, size, or position alone. "Click the red button" or "see the box on the right" fails for anyone who cannot see it; name the thing instead.
• If part of a question is in another language, the problem statement editor cannot mark it for assistive technology on its own. Contact HackerEarth support to set this up.

Images

• When you add an image in the Problem statement toolbar, the Insert image dialog has an Alternative Text field. Describe what the image shows when it carries information a candidate needs. This is what a screen reader reads.

Leave the alt text field empty if your image is purely decorative or if the surrounding description already explains its content. Only provide alt text when the image adds new, visual context needed to solve or understand the question.

• Never put essential information only in an image. Repeat anything a candidate needs (values, labels, or the actual question) in the text of the problem statement.
• Avoid images of text, and never use a screenshot of text, such as sample input, output, or an error message. Type or paste the text into the problem statement instead so it can be read aloud, zoomed, and recolored. Company logos are the only reasonable exception.
• Write formulas with the Math tool in the toolbar, not as images, so a screen reader can read them.
  
  

Tables

• Use the table control in the Problem statement toolbar to build a real table, not a screenshot of one and not characters arranged to look like a table.
• In the table dialog, set Headers to the first row, and to the first column too if the rows have labels. Add a caption if the table needs a title. Without header cells, a screen reader cannot announce column names.
• Keep each table to one idea. A candidate using a screen reader moves through tables cell by cell, so a dense, merged table is hard to follow.
  
  
  
  

Code and formatting

• Use the code control in the problem statement toolbar so the code is real, selectable text, and never an image.
• Do not signal correct, incorrect, pass, or fail with color alone. Add a word or label so the meaning survives for color-blind candidates and screen readers.
  
  
  
  

Attachments

• If your question includes a file a candidate must open to answer, make sure it is in an accessible format: real, selectable text rather than a flat scan of a page.
• Repeat anything essential from the attachment in the Problem statement itself, so a candidate does not depend on the file alone.
  
  
  
  
  

Video and embeds

• If you embed a video, provide captions or a transcript so the content is available without sound.
• If you embed a PDF, make sure it is real, selectable text, not a scanned image of a page.
  
  

Question type

• For a candidate who uses assistive technology, do not assign a Diagram question. The drawing canvas needs a mouse or touch screen and cannot be completed with a keyboard or screen reader. Choose another type instead, such as Multiple Choice Questions, Subjective, or a code-based type.

Links

• Write link text that names the destination, such as "input format guide," not "click here." A screen reader user often scans links out of context, so the words themselves have to say where the link goes.