The three forms, in plain words
A PDF is a file made to look the same on every screen. HTML is the code that web pages are written in. A page in HTML can change its layout to fit the screen, so a full HTML report can fit a phone. An A4 PDF keeps its A4 shape.
The middle form is the easiest to start with. It is one web page for the report. It holds the headline numbers as text, the chairman's message, a list of sections with a link to each, and the PDF. It costs little, and it gives a phone reader and a search engine something to land on.
An interactive annual report usually means charts that react to a tap, or a tool where a reader picks a year or a segment. Each of those needs care. According to the W3C, May 2026, success criterion 2.1.1 (Keyboard, Level A) asks that all functions of the content can be used through a keyboard. A reader who cannot use a mouse must still reach every chart. Our test is simple: press the Tab key through the page before it goes live.
What SEBI's text says about the report on the website
According to SEBI's consolidated LODR text, read in October 2026, Regulation 34(1)(a) asks a listed entity to submit to the stock exchange, and publish on its website, a copy of the annual report sent to shareholders with the notice of the annual general meeting. It must be done on or before the start of dispatch. Regulation 34(1)(b) says that if the report changes, the revised copy goes up with the details of and the reasons for the changes, not later than 48 hours after the annual general meeting.
Regulation 46(2)(l)(iii) lists the complete copy of the annual report, with the balance sheet, profit and loss account, directors' report and corporate governance report, among the items for the website. A proviso to Regulation 46(2) lets the entity give the exact link to the web page of each stock exchange that already holds the information. Ask your company secretary whether it fits your case.
One more point matters for files. A sub-regulation that we read as Regulation 36(4)(b) says disclosures to the stock exchanges and on the website shall be in a format that allows users to find relevant information easily through a searching tool. It adds a proviso. The requirement does not apply where a statutory requirement asks for a format that may not be searchable, such as copies of scanned documents. Whether this reaches a given file is for your company secretary to say.
We found no line in the text we read that names HTML or accessibility. We did not open an official Indian text on accessibility, so we state no legal duty. The list of website items is in our Regulation 46 guide. Our method for the web version is simple. Treat the filed copy as the record, and say so on the page. A line such as "This web version follows the annual report filed on [date]. The filed copy is here" does the job.
What a reader on a phone needs
We did not open a source on how many shareholders read on a phone, so we state no share. We still suggest you design for one. Here is what a phone reader needs, in our reading.
- Text that reads at normal size, without pinching to zoom.
- A short list of links at the top, so the reader can jump to a section.
- The headline numbers as text, near the top.
- Tables that fit the screen, or that scroll inside their own box.
- The file size shown before a download.
- A clear way back to the filed PDF.
Two web standards back this. According to the W3C, September 2026, success criterion 1.4.10 (Reflow, Level AA) asks that content can be used at a width of 320 CSS pixels without scrolling in two directions. That equals a 1280 pixel wide window at 400 percent zoom. The page excepts parts that need a two-dimensional layout, such as maps, diagrams and data tables. For a table, the exception covers the table as a whole and not each cell. So a wide results table may need sideways scrolling, but the paragraphs around it should not.
According to web.dev, February 2019, a page made for many devices needs a viewport meta tag, and forcing a user to scroll sideways or zoom out causes a poor experience. A fixed A4 PDF on a phone is the usual case. The reader pinches and drags. That is why a summary page is worth the work.
The PDF: file basics
Even in a full HTML report, the PDF stays. Get these basics right. They are our checklist, with the sources we read.
- Real text. Export the PDF from the layout file. A scan is a picture of a page, so nobody can search it or copy a line. You can test it: open the file, search for a word and copy one line. The searching-tool line in SEBI's text, above, is one more reason.
- A sensible size. Show the size beside the link, for example (PDF, 8.5 MB, made-up). We state no limit. According to Chrome's Lighthouse documentation, May 2019, large network payloads are highly correlated with long load times, and heavy downloads can cost users money on cellular data.
- A clear name and date. Use one pattern: what it is, the year and the file type. For example, Annual report 2025-26 (PDF). Avoid names like final v3.
- Bookmarks. According to the W3C's PDF technique PDF2, updated June 2026, bookmarks help people find content in long documents, which the page describes as longer than a few pages. The page marks this as advisory, not required.
- Tags, image text and table markup. The W3C's techniques PDF1, PDF6 and PDF16, all updated September 2025, cover alternative text for images, header cells in tables (TH) and the document language in a tagged PDF. They are done in the authoring tool. Ask your designer to show you how the PDF is tagged.
- A link to the filed copy. Say on the page which file is the filed one, as above.
According to Google Search Central, February 2026, PDF is among the file types Google can index. A searchable PDF can be found. A scan gives search nothing to read.
Accessibility in plain words
According to the W3C's WCAG overview, updated 17 September 2026, WCAG 2.2 was published on 5 October 2023 and updated on 12 December 2024. The W3C encourages use of the latest version. Success criteria sit at three levels, A, AA and AAA. The same page says WCAG can also apply to documents, as set out in a companion document called WCAG2ICT. We did not read WCAG2ICT itself. So we read the PDF techniques above as practical help, and we state no rule for PDFs.
The table below turns nine success criteria into plain words, with what each means in an annual report.
| Check | In plain words | WCAG 2.2 criterion | In an annual report |
|---|---|---|---|
| Contrast | Text must stand out from its background. | 1.4.3 Contrast (Minimum), AA: 4.5 to 1 for normal text, 3 to 1 for large text (at least 18 point, or 14 point bold). | Check white text on photos, brand colours and grey notes under tables. |
| Chart colours | The lines, bars and slices must be visible against the background. | 1.4.11 Non-text Contrast, AA: 3 to 1 for the parts of a graphic needed to understand it. | Pale bars on white can fail. Put the values on the bars. |
| Colour alone | Colour must not be the only way to tell things apart. | 1.4.1 Use of Color, A. | Label each line or slice, or use patterns, so a colour legend is not the only key. |
| Text alternatives | Every picture and chart has a text equivalent. | 1.1.1 Non-text Content, A. | The numbers in text beside each chart. |
| Headings, lists, tables | Structure sits in the code, not only in the look. | 1.3.1 Info and Relationships, A. | Real headings in order, and table headers marked as headers. |
| Keyboard | Everything works without a mouse. | 2.1.1 Keyboard, A. | Year pickers, tabs and chart switches all reachable with the Tab key. |
| Language | The page states its language. | 3.1.1 Language of Page, A. | One language tag on each page, and on the PDF. |
| Page title | Each page has a title that says what it is. | 2.4.2 Page Titled, A. | For example: Chairman's message, Annual report 2025-26, company name. |
| Reflow | The page fits a 320 pixel wide screen without sideways scrolling. | 1.4.10 Reflow, AA. | Test on a phone. A wide data table is excepted as a whole. |
We read each W3C Understanding page for these criteria in October 2026. Their dates are: September 2026 for 1.4.3, 1.4.10, 1.4.11 and 1.1.1; May 2026 for 2.1.1; March 2026 for 1.3.1, 3.1.1 and 2.4.2; and September 2025 for 1.4.1. On contrast, the W3C page says images of text also need 4.5 to 1. It says logo text has no requirement.
On language, according to the W3C, March 2026, a screen reader that knows the page language can use that language's pronunciation rules. If a report has a section in Hindi or another language, ask your web team how that section is marked. We did not read the W3C page on language of parts.
Charts: put the numbers in text, next to the chart
A chart is a picture. A person who cannot see it gets nothing from it. So does a person on a small screen where the picture is too small to read. Our rule is plain. For every chart, put the numbers behind it in text, next to it.
The W3C backs this. According to its complex images tutorial, updated 8 April 2026, a chart needs a short description that identifies it, and a long description that gives the essential information in text. The long description may need to carry values and trends, not only the shape. The page also advises making long descriptions available to everyone, in the main content. For a bar chart, the W3C Understanding page on 1.1.1 suggests a short label, a longer description of the chart type with a summary of the data and trends, and, where practical, the data in a table.
We turn that into a pattern of three parts. It is our own method.
- A short alternative text: "Bar chart of sales for five financial years."
- One or two sentences on what the chart shows, taken from the report's own words.
- A small table with the exact numbers, a caption and marked header cells.
On the table, the W3C tables tutorial, updated 16 February 2023, says header cells use the th element and data cells use td. It says a caption names the topic, and that screen readers can read the row and column headers as a user moves through the cells. A table of key figures pasted into the report as a picture is a common case. Rebuild it as a real table.
One note on pie charts. According to the W3C's page on 1.4.11, September 2026, pie slices must be distinguishable from each other unless visible labels and values give the same information. Labels with values on the slices solve it.
What Google can read
According to Google Search Central, February 2026, Google can index HTML and PDF, among many other file types, and image formats such as JPEG, PNG and WebP. The page does not say whether Google reads text inside an image. So we do not rely on it. We put the numbers in text.
According to Google Search Central, March 2026, alt text is the most important attribute for image metadata, Google reads the text around an image to learn its subject, and a descriptive file name gives light clues. So the text you write for a screen reader also helps search.
Two more points are our own reading. A reader's find-in-page box reads only text, so a number inside a picture cannot be found. And a full HTML report gives each section its own address, so a search can land on the right section, while one large PDF has one address. We ran no test, and we promise no ranking.
Speed and page weight
According to web.dev's page on Web Vitals, updated October 2024, three measures describe a good experience. Largest Contentful Paint, for loading, should be 2.5 seconds or less. Interaction to Next Paint, for response to taps, should be 200 milliseconds or less. Cumulative Layout Shift, for content that jumps, should be 0.1 or less. The page says to measure at the 75th percentile of page loads, split by mobile and desktop.
According to Chrome's Lighthouse documentation, May 2019, the audit lists every resource a page requests, and it flags pages whose total goes above 5,000 KiB. A KiB is 1,024 bytes. That page is old, so we treat the number as a rough alarm and not as a goal. A report page with ten large chart images can reach it quickly.
Our practice: one section per page, so the whole report does not load at once. Compress photos. Link the PDF and do not load it inside the page. Keep each interactive chart small. Then test on a mid-range phone over mobile data.
One stable address for each year
People share and save the link to last year's report. A link that breaks costs trust. The W3C note "Cool URIs don't change", written in 1998, says addresses do not change by themselves: people change them. It advises starting from the date a document was issued. It also advises leaving out words that may change, such as old, draft or latest, and file extensions.
Here is a pattern of ours, with a made-up address: /investors/annual-report-2025-26/ for the web version. The year is in the address, and no status word. If you want a page that always shows the newest report, make it a separate page that points to the year page. The W3C note allows a deliberate latest page.
Keep every year live. When you replace a file, keep the address. If the report is revised after the annual general meeting, add a short note that says what changed and when, and keep the older file with its own date. Your company secretary decides the wording. If an address must change, ask the web team for a redirect from the old address, and test it. According to SEBI's LODR text, Regulation 46(3)(b) asks for any change in website content to be updated within two working days from the date of the change.
Say a report with ten charts made readable
Say a listed maker of school furniture has a 120 page annual report with ten charts. This is a made-up example. It is not a real company, and it has no real figures. The company wants a summary page and a full HTML report. For each chart, the team decides on three things.
| Chart | Short alternative text | The text next to it |
|---|---|---|
| 1. Sales for five years (bars) | Bar chart of sales for five financial years | A sentence on the direction, and a table of five values |
| 2. Profit for five years (line) | Line chart of profit for five financial years | A sentence on the direction, and a table of five values |
| 3. Sales by region (pie) | Pie chart of the share of sales in four regions | Labels with values on the slices, and a table of shares |
| 4. Sales by product line (stacked bars) | Stacked bar chart of sales by product line | A table with a row for each product line and a column for each year |
| 5. Cash flow bridge (waterfall) | Waterfall chart from opening to closing cash | The steps as a table, from opening to closing |
| 6. Plants by state (map) | Map of plant locations by state | A list of states with the number of plants |
| 7. Share price for the year (line) | Line chart of the share price over the year | A table with the high and low and their dates |
| 8. Dividend per share (bars) | Bar chart of dividend per share for five years | A table of five values |
| 9. Shareholding pattern (donut) | Donut chart of shareholding by group | A table of groups and shares, taken from the filed pattern |
| 10. Energy use (line) | Line chart of energy use for five years | A sentence, and a table with the unit named |
The team keeps the chart pictures small, adds a caption, and puts the table right under each chart. In the PDF, the same words go in as image text, as in technique PDF1. Finance checks every number against the audited figures before the page goes up. Nothing here needs new software. It needs one person to write ten short texts and ten small tables, and one person to check them.
A build checklist
Use this table before launch and again each year. It is our own method. A shorter cousin of it, for the investor page, is in our investor page guide.
| Check | What to look for | Who | When |
|---|---|---|---|
| Form chosen | One of the three forms, written in the brief with the reason | Finance, company secretary, web lead | Before design |
| Filed copy | The web version matches the filed report, and the page says which copy is the record | Company secretary | Before launch |
| PDF text | Search a word and copy a line. Both work | Designer | Each export |
| PDF structure | Tags, image text, table headers, language and bookmarks | Designer | Each export |
| Name, date, size | One naming pattern, with the size beside the link | Web team | Each upload |
| Chart texts | Every chart has a short alternative and its numbers in text | Designer and finance | Before proof |
| Contrast | 4.5 to 1 for normal text, 3 to 1 for large text and chart parts. Use a checking tool | Designer | At design |
| Keyboard | Press Tab through the whole page. Every link, tab and picker works | Web team | Before launch |
| Headings, tables, language, title | Headings in order, header cells marked, a language tag, a page title | Web team | Before launch |
| Phone test | A mid-range phone on mobile data: load, sideways scroll, taps | Web team | Before launch and each year |
| Speed | Web Vitals read for mobile, and the page weight | Web team | Before launch |
| Stable address | Year in the address, old years live, any redirect tested | Web team | At launch and each year |
| Owner | One named role with a stand-in | The company | Each year |
For a monthly check of a website, see our website audit. For the design of the report itself, see our notes on annual report design trends.
Common mistakes
These are our own observations of how reports go on the web. They are not findings from SEBI or from any named company.
- A scanned PDF on the investor page, so nothing can be searched.
- Charts as pictures, with no text beside them.
- A table of figures pasted in as a picture.
- White text on a photo, or pale grey notes under a table.
- A web version that differs from the filed copy, with no line that says which one is the record.
- An address with the word latest or final in it, which changes every year.
- Interactive charts that work only with a mouse.
- A very large file with no size shown.
- A web version planned after the print files are done, so nobody has time for chart texts.
- No owner, so next year's report starts from nothing.
This is general information, not legal advice. For your case, speak to a lawyer or your company secretary. Last checked: 26 October 2026.
