Private corporate batches, live online cohorts and 1-on-1 mentoring in semantic markup, accessible documents and the browser rendering path — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches HTML as the contract between a build pipeline and a browser rather than as a tag list — document structure and the parsing model, semantic sectioning, native form validation, the head elements that govern encoding, viewport and script loading, and the media elements with their formats and events. Sessions run against real pages in DevTools, and every module ends with the markup being validated, accessibility-scanned and measured, so attendees leave able to defend a page in an audit rather than only render it.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For HTML that means a trainer who has run it in production — semantic markup, accessible documents and the browser rendering path — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private HTML batchHTML — HyperText Markup Language — is the markup the browser parses to build the document model that every stylesheet, script, screen reader and crawler then works against. It is not a programming language. It declares structure and meaning: this is a heading, this is a navigation region, this is a form control, this is a table cell. From that declaration the browser constructs a DOM, an accessibility tree, a render tree and a list of network requests for the assets the document references.
The modern language is HTML5, and most of what matters sits in three places. Sectioning and text semantics — header, nav, main, article, section, aside, footer, and the inline elements that carry emphasis, citation and edit history — decide what assistive technology and search engines can understand. Forms carry input types, constraint attributes and native validation that remove whole categories of hand-written JavaScript. The head element controls character encoding, viewport behaviour, metadata, stylesheet links and script loading order, which is where most first-paint problems are actually created.
In a delivery pipeline HTML is rarely hand-written end to end. It is emitted by templates, static site generators or a framework build step, then minified, fingerprinted and served from a CDN. That makes markup correctness a build concern rather than an editorial one: validation, accessibility scanning, link checking and performance budgets belong in CI, where a malformed table, a missing alt attribute or a render-blocking script fails a pull request instead of reaching production.
Every web interface, internal dashboard, status page, documentation site and email template an organisation ships is HTML by the time it reaches a browser. Frameworks change every few years; the output does not. Engineers who understand what the browser does with markup debug rendering, layout and accessibility problems in minutes, and engineers who do not treat the DOM as an opaque side effect of their component library.
Two pressures have made this a hiring concern rather than a background skill. Accessibility is now a legal and procurement requirement in most large markets, and the majority of findings in an audit are markup defects — unlabelled controls, missing landmarks, images without alternative text, headings used as styling. Core Web Vitals turned document structure and resource loading into a measurable, ranked score, so the head section and the order of scripts and stylesheets have direct commercial consequences.
What teams are short of is not people who can write a div. It is engineers who can produce markup that validates, passes an accessibility audit, survives templating, and keeps its performance budget after a build step has minified and bundled everything around it.
The parsing model before the tag list. What HTML is, what a browser builds from it, and why some mistakes are silently repaired while others corrupt the whole document. Document structure, the doctype declaration, elements and nesting, empty elements, case sensitivity and the attribute rules that prevent most first-week defects.
Topics: What HTML is and what the browser constructs from it · A minimal document and the doctype declaration · Elements, nested elements and never skipping the end tag · Empty and void elements · Case sensitivity, lowercase tags and quoted attribute values · Core attributes — href, src, width, height, alt, style, lang, title · Viewing and reading page source in DevTools
The elements that carry meaning rather than appearance. Heading hierarchy and why it is a navigation structure rather than a font size, paragraphs and the whitespace model, the formatting and edit-tracking elements, and the quotation and citation set that most pages either skip or misuse.
Topics: Headings, heading order and why size is not the point · Paragraphs, the whitespace problem and preformatted text · Horizontal rules and line breaks · Formatting elements — b and strong, i and em, small, mark, del, ins, sub, sup · Quotation and citation — blockquote, q, abbr, address, cite, bdo · Block-level versus inline elements · Comments and what should never be left in them
How a document references everything outside itself. Link syntax and targets, absolute versus relative URLs and the path structure that decides whether a build survives being deployed under a different prefix, then images with the attributes that control layout stability and accessibility.
Topics: Link syntax, the target attribute and link titles · Absolute versus relative URLs, and path structure in a built site · Images as links, buttons as links, and mailto links · Image syntax — src, alt, width and height · Width and height attributes versus style, and layout shift · Common image formats and when each is correct · Image maps and image tags reference
Tabular and list data done properly, which is where most accessibility audits find their easiest wins. Table definition, headers, captions, spanning cells and border behaviour; ordered, unordered and description lists; and the grouping elements that give CSS something to target without adding meaningless wrappers.
Topics: Defining a table — rows, cells, header cells and captions · Cells that span rows and columns · Borders, collapsed borders, cell padding and border spacing · Heading alignment and table styling boundaries · Unordered, ordered and description lists · List nesting and the list tag reference · Grouping content without div soup
The section nobody demonstrates and everybody gets wrong. Title, style, link, meta, base and script inside head, then the loading consequences: what blocks rendering, what blocks parsing, what defer and async actually change, and why script placement decides first paint more than any amount of CSS tuning.
Topics: The head element and what belongs in it · title and its role in tabs, bookmarks and search results · The style and link elements, and stylesheet loading · The meta element — charset, viewport, description and robots · The base element and the problems it solves and creates · The script element in head and body, plus defer and async · The noscript element and progressive enhancement
Markup decisions determine how maintainable the styling and behaviour layers are. The global attribute set, the difference between id and class, multiple classes and shared classes, bookmark links built on id, and the naming discipline that stops a stylesheet from calcifying.
Topics: The global attribute set and the full attribute reference · The class attribute — syntax, multiple classes, shared classes · The id attribute and the difference from class · Bookmarks and in-page links built on id · Using class and id from JavaScript · Data attributes for behaviour hooks · Naming conventions that survive a design change
The markup that layout techniques expect. Layout elements and the sectioning set, an honest comparison of float, Flexbox, Grid and framework-driven layout from the markup's point of view, then iframes — syntax, sizing, borders, link targeting, and the security posture they demand.
Topics: Layout elements and layout techniques · Float layout, Flexbox layout and Grid layout — markup implications · CSS frameworks and the markup they impose · Iframes and iframe syntax · Setting iframe height and width, and removing the border · Using an iframe as a link target · Sandboxing, referrer policy and third-party embeds
The most functional part of HTML and the most commonly reimplemented in JavaScript for no reason. The form element and its attributes, the input family, labels and their association rules, and the native validation behaviour that already handles most of what hand-written validators do badly.
Topics: The form element and the input element · Text fields, radio buttons, checkboxes and the submit button · The label element and correct label association · The name attribute and how data is actually submitted · Form attributes — action, target, method, autocomplete, novalidate · Input types, constraint attributes and native validation · Accessible error messaging and required fields
Native multimedia without a plugin. What multimedia means in the browser, format and codec support, then the video and audio elements in detail — sources and fallbacks, autoplay and its restrictions, media types, and the methods, properties and events that make a custom player possible.
Topics: What multimedia is and where browser support still differs · Multimedia formats — common video and audio formats · The video element and how it works · Video autoplay, muting and browser policy · Video media types and multiple sources · Video and audio methods, properties and events · The audio element, formats and media types · Captions, tracks and accessible media
Where markup meets CI. Accessibility beyond alt text, structured data for search, then the automation: markup validation, link checking, accessibility scanning and Lighthouse budgets as pipeline gates, and what templating, minification and fingerprinting do to the document you wrote.
Topics: Landmarks, focus order, tabindex and ARIA — and when ARIA is the wrong answer · Screen reader testing as part of review · Markup validation and html-validate in CI · Link checking and broken-asset detection · Structured data and social metadata · Templating engines and generated markup · Minification, fingerprinting and cache headers · Lighthouse and Core Web Vitals budgets as build gates
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a page built entirely from nested divs and rebuild it with sectioning elements, a correct heading outline and real landmarks, then compare the two accessibility trees.
Rebuild a form that validates with a hand-written script so it uses input types, constraint attributes and labels, and behaves correctly with the keyboard alone.
Profile a slow page in DevTools, then reorder stylesheets and scripts, apply defer and async correctly, and prove the improvement with measurements rather than opinion.
Ship a video element with multiple encoded sources, a poster image, captions and a custom control built on media events, then measure its effect on page weight.
Convert a layout table into CSS-driven layout, then mark up a genuine data table with captions and header associations and verify it with a screen reader.
Wire validation, link checking, an accessibility scan and a Lighthouse budget into CI so a broken heading order or a missing alt attribute fails the pull request.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.