Website Accessibility Audit Service in India: A 30-Day Business Plan for Freelancers

A customer should be able to complete a purchase without a mouse. A form should tell a screen-reader user which field needs attention. A button should remain visible when someone zooms in. These are ordinary customer-experience questions, but many websites still handle them poorly. For Indian freelancers, designers, developers and agencies, accessibility auditing can become a focused service built around real user journeys.You do not need to build an AI model or sell expensive software. You need to understand accessibility standards, test carefully, explain problems and help clients fix them. This guide covers audit methods, automation limits, standards in India, pricing examples, a client report and a 30-day launch plan. It also explains why an audit is not the same as a blanket legal compliance certificate.What is a website accessibility audit?An accessibility audit checks whether people with different abilities can use a website or digital product. It examines navigation, forms, content, interactions, media and compatibility with assistive technology. Common problems include missing image alternatives, unlabeled controls, poor keyboard navigation, unclear error messages and text with insufficient contrast.An audit is not simply a tool score. The World Wide Web Consortium, or W3C, explains that automated tools cannot check every accessibility requirement. Human judgement and manual testing are essential. A scanner may flag a missing image description, but it cannot reliably decide whether the description gives a shopper the information needed to choose a product.Which accessibility standards apply in India?The Web Content Accessibility Guidelines, WCAG, are an international reference. WCAG 2.2 became a W3C Recommendation on 5 October 2023. It includes levels A, AA and AAA. Meeting Level AA means satisfying all applicable Level A and AA success criteria, not selecting only a convenient few.India's Guidelines for Indian Government Websites and Apps, GIGW 3.0, describe conformity with WCAG 2.1 Level AA for government websites and apps. Do not claim that this automatically imposes the same standard on every private ecommerce store. Legal, sector, procurement and contract obligations can differ. Agree the target standard and scope in writing, and seek qualified advice for formal legal claims.Where the service opportunity comes fromSmall websites are often built for launch speed, appearance or conversion without a structured accessibility review. Owners may not know whether keyboard-only visitors can check out, whether booking errors are announced or whether their documents can be read with assistive technology. A specialist can identify barriers, rank their impact and provide a clear remediation plan.The service fits ecommerce stores, SaaS dashboards, education platforms, clinics, booking sites and agencies that build client websites. The opportunity is not based on claiming that every company is legally required to buy an audit. It is based on offering better usability, more inclusive design and measurable product quality.Choose one customer segment firstCustomerJourneyDeliverableEcommerceSearch, product, cart, checkoutPurchase barrier reportSaaSSignup, login, dashboardKeyboard and form reviewClinicFind service and bookBooking accessibility auditTraining providerCourse search and enrollmentLearning journey reviewAgencyTemplates and reusable componentsDesign and code fix listA checkout audit is easier to explain than an offer to make every digital product accessible. Each segment has repeatable journeys and problems. Start with one type, build a sample report and learn which issues clients are willing to fix.Follow a repeatable audit methodW3C's WCAG Evaluation Methodology, WCAG-EM, provides a useful structure: define scope, explore the product, choose representative pages, evaluate them and report findings. Follow these stages even when delivering a small pilot. The method is more defensible than scanning a homepage and claiming the whole website passed.Step 1: Define scopeRecord the site URL, languages, target standard and level, devices, browsers, included page types and user journeys. Confirm whether you can test logged-in areas with dummy accounts. Define how many interactive states and retest rounds are included. Ten nearly identical product pages are not the same effort as ten different application workflows.Step 2: Run automated checksUse suitable accessibility evaluation tools to find potential issues. Record tool names, versions, pages tested and results. Scanners can help detect missing labels, contrast problems and some structural issues. They cannot determine complete accessibility. W3C cautions that automated tools can miss barriers or produce misleading results.Step 3: Test keyboard navigationPut the mouse aside. Can you reach navigation, search, filters, product options, cart and checkout? Is keyboard focus visible? Does it move logically? Can you leave menus and dialogs? Repeat at different screen widths. Sticky headers and pop-ups can hide focused controls. WCAG 2.2 includes a criterion addressing focus that is obscured by content.Step 4: Review content and formsCheck heading order, descriptive link names, meaningful image alternatives, field labels, instructions and error messages. A red border alone does not explain why a form failed. The error should identify the problem in text and help the user correct it. Decorative images may need no spoken description, while important product images need useful alternatives.Step 5: Test with assistive technologyUse an appropriate screen reader and browser combination. Review how headings, controls, live updates and errors are announced. Seek feedback from experienced users with disabilities where possible. Document the environment. Passing in one browser and screen reader does not prove identical behaviour across every combination.Step 6: Prioritise and verify fixesFor each issue, record the affected page, user impact, relevant criterion, steps to reproduce, screenshot or recording, suggested fix, owner and retest status. Ask clients to fix blocking problems first. Retest the exact journey after changes. A useful report tells the development team what to do next.Example: An ecommerce checkout auditImagine a D2C store with 120 products. The owner asks for five representative pages: homepage, category, product detail, cart and checkout. You also test search, a discount code and an error state. Suppose the size selector cannot be used from the keyboard, the discount error has no text explanation, and the checkout confirmation is not announced to a screen reader. These are illustrative findings, not results from a real store.Prioritise the size selector because it blocks buying. Next, fix the checkout confirmation because customers need to know whether the order succeeded. The discount message still matters, but its impact may be less severe. Report the affected journey, the exact barrier and a clear acceptance test rather than sending a long export of scanner warnings.How to price an audit serviceQuote based on scope and effort, not an invented national standard fee. Suppose a five-template audit requires four hours of setup, eight hours of manual testing, four hours of reporting and four hours of retesting. Total effort is 20 hours. If your internal target recovery is ₹1,500 per productive hour, labour target is ₹30,000. Add direct tools, administration and a contingency before quoting.If the quoted fee is ₹40,000 and direct delivery cost is ₹26,000, contribution before fixed overhead is ₹14,000. Contribution margin is ₹14,000 divided by ₹40,000, or 35%. These are example economics, not surveyed market rates or guaranteed earnings.OfferScopeMain deliverableQuick reviewOne journey and selected pagesPrioritised issue listStandard auditSeveral templates and interactionsEvidence-backed reportRemediation supportFix review and retestingVerified issue closureMonthly monitoringAgreed key journeysRegression reportDo not sell unlimited pages or revisions for a fixed fee. Define page types, journeys, retest rounds and what counts as additional work. A clearly scoped small project is easier to deliver profitably than an open-ended promise.Where AI helps and where it does notAI can organise findings, draft plain-language explanations, group repeated issues and suggest code changes for human review. It can also turn a technical report into tasks for a developer. It should not invent test results, declare WCAG conformance without adequate evaluation or replace screen-reader testing. Obtain permission before uploading client screenshots, code or private data to an external tool.Find your first three clientsChoose a known customer segment. Build a sample audit using your own demo website or a site you have permission to test. Show before-and-after behaviour instead of a made-up compliance badge. Contact web design agencies, ecommerce developers and SaaS teams with a short paid diagnostic offer and a clear list of deliverables.Agency partnerships can work well if responsibilities and client communications are defined. Nitross's productized services guide explains how to package repeatable work. Its customer acquisition cost guide helps assess whether outreach is commercially sensible.A 30-day launch planDaysFocusOutput1-7Learn standards and choose one segmentAudit checklist8-14Test a demo websiteSample report15-21Approach potential clientsPaid pilot proposals22-30Deliver a pilot and collect feedbackPermission-based case studyDo not publish a client's accessibility weaknesses without permission. A case study can describe the type of issue, fix and outcome while protecting sensitive details.Common mistakesCalling an automated scan a complete WCAG audit.Promising legal compliance across every Indian sector.Testing only the homepage and claiming the whole site passed.Ignoring logged-in journeys, mobile views and error states.Treating decorative and informative images identically.Quoting a fixed price before counting templates and interactions.Using AI-generated findings without reproducing them.Delivering a report with no priorities or retest plan.Frequently asked questionsDo I need to be a programmer?You need enough accessibility and technical knowledge to evaluate issues accurately. Developers can offer remediation, while trained auditors may focus on evaluation. Complex products often need both.Can free tools complete the audit?No. W3C explains that some checks require human evaluation. Tools help identify issues but cannot establish complete accessibility by themselves.Is WCAG 2.2 Level AA mandatory for every private Indian website?Do not assume that. Requirements depend on the organisation, sector, contract and applicable law. GIGW 3.0 specifically addresses government websites and apps and references WCAG 2.1 Level AA.What should a client report contain?Scope, standard, testing environment, methodology, issue evidence, impact, recommended fixes, priorities, limitations and retest status.How can a freelancer earn recurring revenue?Offer scheduled regression checks after website updates. Test agreed journeys and components, report new barriers and charge for a defined monitoring scope.What to do todayChoose a demo checkout or booking form. Test it without a mouse, then review it with an accessibility tool and screen reader. Write five findings with evidence and practical fixes. That report is a stronger starting point than a claim that every site can become 100% accessible with one scan.SourcesW3C, WCAG 2.2 changesW3C, WCAG Evaluation MethodologyW3C, Selecting Evaluation ToolsGovernment of India, GIGW 3.0