Website Accessibility Malaysia: WCAG 2.2 Checklist for Business Websites

A website can look attractive, load quickly and work well on mobile devices while still being difficult for some people to use.

For example, a visitor may be unable to use a mouse comfortably, have low vision, rely on a screen reader, find certain colour combinations difficult to distinguish, navigate primarily with a keyboard or need content to be presented in a clearer and more predictable way.

Accessibility problems are not always obvious to the business owner.

A website may appear completely normal when used with a laptop and mouse but still contain barriers such as:

• Buttons that cannot be reached using a keyboard.
• Focus indicators that are difficult or impossible to see.
• Text with insufficient colour contrast.
• Important images without suitable alternative text.
• Form fields without clear labels.
• Error messages that rely only on colour.
• Popups that interfere with keyboard navigation.
• Mobile buttons that are too small or too close together.
• Important video content without captions.
• Page structures that are difficult for assistive technologies to understand.

This is what website accessibility is designed to address.

This Website Accessibility Malaysia guide explains the practical foundations of WCAG 2.2 for business owners, including alt text, colour contrast, keyboard navigation, focus management, headings, forms, mobile accessibility, screen readers, media, testing and the questions you should discuss with a web designer or developer.

Quick Answer: What Is Website Accessibility?

Website accessibility is the practice of designing and developing websites so that more people can access, understand, navigate and use their content and functionality, including people with different disabilities.

This can include users with:

• Visual impairments or low vision.
• Blindness.
• Colour vision deficiencies.
• Limited mobility.
• Hearing impairments.
• Cognitive or learning differences.
• Users who rely on assistive technologies.

However, accessibility is not useful only to one specific group.

Many accessibility practices can also improve usability for:

• Smartphone users.
• People who prefer keyboard navigation.
• Users on small screens.
• Older users.
• People using a screen in bright sunlight.
• People with temporary injuries.
• Anyone who benefits from a clearer and more predictable interface.

What Is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines.

It is published by the World Wide Web Consortium, or W3C, and is widely used as a technical reference for web accessibility.

The version discussed in this guide is WCAG 2.2.

WCAG is organised around four main principles, often summarised as POUR:

Principle	Practical Meaning
Perceivable	Information should be presented in ways users can perceive
Operable	Interface components and navigation should be usable
Understandable	Content and interactions should be understandable
Robust	Content should work reliably with suitable browsers and assistive technologies

Malaysia also has accessibility guidance within the Malaysia Government Design System, or MYDS, which references WCAG 2.2 for accessible digital applications.

For a local technical reference, see the MYDS Accessibility guide.

Does Every Malaysian Business Website Have to Meet WCAG 2.2?

Do not assume that every private-sector website in Malaysia has exactly the same legal obligation to achieve a particular WCAG conformance level.

Accessibility requirements can depend on factors such as:

• The type of organisation.
• The sector.
• Government or public-sector requirements.
• Tender or procurement requirements.
• Contractual requirements.
• Industry requirements.
• Other jurisdictions relevant to the organisation.

If accessibility is required for a tender, compliance obligation, public service or contractual requirement, confirm the exact requirement with the appropriate legal, procurement or compliance representative.

This article is a practical web design and development guide. It is not legal advice or formal WCAG certification.

What Is the Difference Between an Accessible Website and a WCAG-Conformant Website?

The phrase accessible website can be used generally to describe a website designed to reduce barriers for users.

WCAG conformance has a more formal meaning.

WCAG includes several conformance levels:

• Level A.
• Level AA.
• Level AAA.

Do not claim that a website is “WCAG 2.2 AA compliant” simply because:

• The colours appear easy to read.
• The images have alt text.
• An accessibility toolbar has been installed.
• An automated checker gives the site a high score.

Formal conformance requires the applicable success criteria and complete user processes to be assessed, not just one visual feature or automated score.

1. Start With Semantic HTML

Good accessibility begins with structure.

Semantic HTML helps browsers and assistive technologies understand the purpose of elements on a page.

Use appropriate elements for:

• Headings.
• Paragraphs.
• Lists.
• Links.
• Buttons.
• Forms.
• Tables.
• Navigation.
• Page landmarks.

Avoid building every interaction with generic containers when native HTML already provides an appropriate element.

For example, something that behaves like a button should use proper button behaviour rather than being only a box styled to look like a button.

Nibong Web Studio also considers semantic headings and page structure among the technical areas covered in Website Development.

2. Use a Logical Heading Structure

Headings help users understand the hierarchy of page content.

A typical structure may use:

• H1 for the main page topic.
• H2 for major sections.
• H3 for subsections.

Do not choose H2, H3 or H4 simply because the default font size looks visually suitable.

Visual appearance can be controlled through design, while the heading structure should represent the real relationship between sections.

A clear heading structure can also help with:

• Screen-reader navigation.
• Content scanning.
• SEO structure.
• User comprehension.

3. Provide Alt Text for Images That Carry Information

Alt text, or alternative text, provides an equivalent description or purpose when an image cannot be perceived visually.

The correct alt text depends on the purpose of the image.

Product image

If the image shows a product that is important to the content, the alt text should describe the relevant information.

Functional icon

If an icon is used as a control, its accessible name should explain the function rather than only describing what the icon looks like.

Decorative image

If an image is genuinely decorative and adds no useful information, it may not need descriptive alt text.

Do not use alt text as a place to insert unnecessary SEO keywords.

The primary purpose is to communicate the function or relevant information of the image.

4. Do Not Put Important Information Only Inside Images

A promotional graphic containing all important information inside a JPG or PNG can create accessibility problems.

Examples include:

• Price lists.
• Service details.
• Event dates.
• Phone numbers.
• Terms.
• Instructions.

Important information should also be available as actual readable page content where appropriate.

This helps accessibility, responsive behaviour, search engines and users who need to zoom, select or copy the text.

5. Make Sure Colour Contrast Is Sufficient

Very light grey text on a white background may look visually minimal, but it can be difficult to read.

For WCAG 2.2 Level AA, normal text generally requires a contrast ratio of at least 4.5:1, while large text generally uses a 3:1 threshold.

Contrast should be measured using the actual colour values rather than judged only by appearance on the designer's monitor.

Pay particular attention to:

• Body text.
• Small labels.
• Placeholder text.
• Footer text.
• Buttons.
• Links.
• Error states.
• Interactive components that visually resemble disabled elements.

6. Do Not Use Colour as the Only Way to Communicate Meaning

Form validation should not rely only on:

Red = incorrect

and:

Green = correct.

Use additional cues such as:

• Text messages.
• Icons.
• Labels.
• Other visual indicators.

Likewise, charts should not depend on colour alone when users need to distinguish between categories.

7. Important Website Functions Should Be Usable With a Keyboard

Some users do not use a mouse.

They may navigate with:

• A keyboard.
• A switch device.
• Voice input.
• Assistive technology that produces keyboard-style interactions.

Test the website with:

• Tab.
• Shift + Tab.
• Enter.
• Space.
• Arrow keys where relevant.
• Escape for menus or dialogs where appropriate.

Make sure users can reach and operate important functionality such as:

• Navigation.
• Dropdown menus.
• Buttons.
• Forms.
• Tabs.
• Accordions.
• Modals.
• Carousel controls.
• Booking or enquiry actions.

8. Avoid Keyboard Traps

A keyboard trap occurs when a user can enter a component using the keyboard but cannot leave it in the expected way.

This can happen in:

• Modals.
• Popups.
• Chat widgets.
• Date pickers.
• Video players.
• Custom menus.

Test the complete interaction, not just whether the first Tab press works.

9. Focus Indicators Need to Be Visible

When someone presses Tab, they should be able to see which interactive element currently has keyboard focus.

A focus indicator may use:

• An outline.
• A border.
• A background change.
• Another sufficiently visible visual treatment.

Do not disable the browser's focus style without providing a suitable replacement.

Focus is important because it shows keyboard users where they are on the page.

10. Make Sure Focus Is Not Hidden Behind Sticky Elements

Sticky headers, cookie banners, floating WhatsApp buttons or fixed footers can cover an element that currently has focus.

During keyboard testing, make sure the focused component remains visible and is not completely hidden behind another interface element.

11. Buttons and Touch Targets Should Be Easy to Activate

WCAG 2.2 places additional attention on target size.

For Level AA, the Target Size Minimum success criterion uses a threshold of 24 by 24 CSS pixels, with specified exceptions.

In practical design, larger controls with adequate spacing can often be easier to use on mobile devices.

Pay particular attention to:

• Small icon buttons.
• Carousel arrows.
• Close buttons.
• Pagination.
• Checkboxes.
• Calendar controls.
• Floating action buttons.

12. Do Not Make Dragging the Only Way to Complete a Task

If a user must drag an item, provide another method where the same function can reasonably be completed without dragging.

Alternatives can include:

• Reordering using buttons.
• Moving an item with controls.
• Selecting a destination through a menu.

Dragging can be difficult for users with limited motor control.

13. Form Fields Need Clear Labels

A placeholder is not a complete replacement for a visible form label.

Labels help users understand:

• What information is required.
• The expected format.
• The purpose of the field.

Examples include:

Name

Email

Phone Number

Required Service

The label should also be programmatically associated with the form field where relevant so assistive technologies can identify the relationship.

14. Required Fields Should Be Identified Clearly

If a form field is compulsory, do not indicate this only with a red border.

Use clear wording or another understandable indicator.

For example:

Email — required

or another indicator that is properly explained to users.

15. Error Messages Should Explain What Went Wrong

An error message such as:

Invalid input.

is not very helpful.

A more useful message might say:

Please enter a valid email address.

Where possible:

• Identify the field with the problem.
• Explain what is wrong.
• Tell the user how to correct it.
• Avoid deleting all the information they have already entered.

16. Avoid Asking Users to Enter the Same Information Repeatedly Without a Good Reason

WCAG 2.2 includes attention to redundant entry within certain user processes.

If the user has already provided information during the same process, avoid asking for the same information again when it can reasonably be reused or selected.

This can help users with memory or cognitive difficulties and also makes the process easier for everyone.

17. Authentication Should Not Depend Only on Cognitive Tests

A login process can become difficult when users are required to perform cognitive tasks without an appropriate alternative.

Examples can include requiring the user to:

• Memorise complex information.
• Solve a puzzle.
• Transcribe information without an alternative method.

If your website contains login, membership or customer-account functionality, accessible authentication should be considered as part of the complete user journey.

18. Mobile Accessibility Is More Than Responsive Design

A website can be responsive and still be difficult to use.

On mobile devices, test:

• Button size.
• Spacing.
• Navigation menus.
• Forms.
• Sticky buttons.
• Popups.
• Tables.
• Horizontal scrolling.
• Zoom.
• Orientation.
• Text size.

If you are building or updating a website, Nibong Web Studio's Web Design service focuses on clear website structure and mobile-friendly presentation for business websites.

19. The Website Should Remain Usable When Text Is Enlarged

Some users need to zoom or increase text size.

When text becomes larger:

• Content should not overlap unnecessarily.
• Buttons should not disappear.
• Important information should not be cut off.
• Users should not need unreasonable scrolling just to read basic content.

Responsive layouts should be reviewed under zoom, not only at the browser's default settings.

20. Use Clear Link Text

A link such as:

Click here

can be difficult to understand when read without the surrounding sentence.

More descriptive link text could be:

View website packages

or:

Read the Website Speed Malaysia guide

Screen-reader users may navigate through a list of links, so descriptive wording can make the destination easier to understand.

21. Keep Navigation Consistent

If the main navigation changes unexpectedly from one page to another, users can become confused.

Consistency matters for:

• Header navigation.
• Footer navigation.
• Help and contact locations.
• Forms.
• Button styles.
• Repeated components.

Predictable interfaces can be especially useful for users who need greater consistency while navigating.

22. Provide a Way to Skip Repeated Content Where Appropriate

On websites with long navigation menus, keyboard and screen-reader users may otherwise need to move through the same menu every time they open a new page.

A “Skip to content” link is one common pattern that allows users to move directly to the primary content.

It may remain visually hidden until it receives keyboard focus, but it still needs to work correctly.

23. Screen Reader Testing Is Not the Same as Looking at the HTML

A screen reader is assistive technology that communicates information in an interface through speech or another output method.

A website can look correct visually while still being confusing to a screen reader if:

• The heading structure is incorrect.
• Buttons do not have accessible names.
• Form labels are not associated correctly.
• Status changes are not announced.
• Important images have no suitable alt text.
• Custom controls use inappropriate markup.

When accessibility is an important project requirement, test with real assistive technology rather than relying only on automated scanning.

24. Use ARIA Only When Necessary

ARIA can provide roles, states and accessible names for certain custom components.

However, ARIA is not a replacement for good HTML.

Where native HTML already provides the required semantic behaviour, use the native element when practical.

Incorrect ARIA can make an experience more confusing rather than more accessible.

25. Dynamic Status Messages Need to Be Communicated Properly

Modern websites can update content without reloading the page.

Examples include:

• A form being successfully submitted.
• An item being added to a cart.
• Search results being updated.
• Loading being completed.

If a status change is only visual, some assistive-technology users may not know that anything has changed.

Dynamic interfaces should be designed so that important changes of state can be communicated appropriately.

26. Video Content Should Consider Captions

If a video contains spoken information that is important to understanding the content, captions can help users who cannot hear the audio clearly.

Captions can also be useful when:

• The user is in a noisy environment.
• The device is muted.
• The spoken language is not the user's strongest language.

Do not rely blindly on automatically generated captions when accuracy is important.

27. Audio Description May Be Relevant for Important Visual Information

If a video communicates important information only through visuals and not through narration, the accessibility plan may need to consider an alternative description.

The appropriate solution depends on the type of video and the information being communicated.

28. Avoid Animation or Flashing That Creates Barriers

Animation is not automatically an accessibility problem.

However, excessive movement can be difficult for some users.

Review:

• Autoplay animation.
• Parallax effects.
• Rapid flashing.
• Scroll-triggered motion.
• Animations that cannot be stopped.

An attractive website does not need to depend on excessive movement.

29. Carousels Should Be Controllable

A carousel that automatically changes too quickly can make content difficult to read.

If you use a carousel, consider:

• Previous and next controls.
• A pause option where appropriate.
• Keyboard access.
• Clear focus indicators.
• Enough time for users to read the content.

For many business websites, static content can also be clearer and easier to use than a complex carousel.

30. Modals and Popups Need Proper Focus Management

A modal may be used for:

• Forms.
• Cookie settings.
• Login.
• Promotions.
• Confirmations.

Make sure:

• Focus moves into the modal appropriately.
• Keyboard users can navigate inside it.
• The close control is clear.
• Escape works where appropriate.
• Focus returns to the correct location when the modal closes.
• The background content does not create unnecessary confusion.

31. Use Tables for Data, Not Page Layout

If a table is used for actual tabular data, use a structure that allows relationships between headers and data cells to be understood.

For general page layout, use modern layout techniques rather than tables.

Large data tables should also be tested on mobile because horizontal overflow can reduce usability.

32. PDFs Can Also Have Accessibility Problems

Website accessibility does not end with HTML pages.

If your website provides files such as:

• Brochures.
• Annual reports.
• Forms.
• Price lists.
• Company profiles.
• Other PDF documents.

those documents can also be difficult to use if they are simply scanned images or lack meaningful document structure.

Where important information can reasonably be provided as an HTML page, consider giving users that option as well.

33. Do Not Assume an Accessibility Widget Fixes Everything

A toolbar that allows users to change font sizes, contrast or colours can provide some convenience.

However, it does not replace accessibility work within the underlying website.

For example, a widget may not fix:

• Keyboard traps.
• Incorrect heading hierarchy.
• Missing form labels.
• Incorrect accessible names.
• Poor focus management in modals.
• Inaccessible custom components.

Accessibility needs to be considered within the structure, design and interactions of the website itself.

34. Automated Accessibility Tools Are Useful — But Not Enough

Automated tools can help identify issues such as:

• Some colour-contrast problems.
• Missing alt attributes.
• Certain ARIA errors.
• Duplicate IDs.
• Some form-related issues.

However, software cannot assess every accessibility issue automatically.

For example, a tool may detect that alt text exists but cannot always determine whether the wording accurately communicates the purpose of the image.

A stronger accessibility review can combine:

• Automated checks.
• Manual review.
• Keyboard testing.
• Screen-reader testing where relevant.
• Mobile testing.
• User testing when accessibility is an important project requirement.

35. An Accessibility Audit Is Not the Same as a General Website Audit

A general website audit may review areas such as:

• Business messaging.
• SEO.
• Performance.
• Forms.
• Content.
• Mobile experience.
• Security.
• Analytics.
• Some accessibility basics.

A more formal accessibility assessment requires specialised testing against the applicable WCAG success criteria and complete user journeys.

Do not treat a general website audit as proof of formal WCAG conformance.

36. Accessibility and SEO Overlap in Some Areas — But They Are Not the Same

Some accessibility practices also align with good website structure.

Examples include:

• Semantic headings.
• Clear link text.
• Useful image alternatives.
• Logical content structure.
• Mobile usability.
• Understandable navigation.

However, do not claim that WCAG conformance guarantees improved Google rankings.

Accessibility and SEO have different primary objectives.

For an SEO-specific technical review, see our Technical SEO Checklist Malaysia.

37. Accessibility and Website Performance Need to Work Together

An accessible interface should not require the website to become unnecessarily heavy.

Likewise, performance optimisation should not remove important functionality or accessible labels simply to obtain a higher score.

Performance and accessibility can be planned together.

If your website is slow, read Website Speed Malaysia to understand Core Web Vitals and common website-performance problems.

38. Accessibility Is Easier to Plan From the Beginning Than to Retrofit Later

If accessibility is discussed during the planning stage, the designer and developer can consider:

• Colour palette.
• Component design.
• Heading structure.
• Forms.
• Navigation.
• Keyboard interaction.
• Focus states.
• Responsive behaviour.
• Media.

If the website has already been fully designed and developed, accessibility improvements may require more rework.

If accessibility is important to your project, include the requirement in the website brief before development begins.

Use our Website Brief Malaysia guide to organise your business, content and functionality requirements before requesting a quotation.

39. When Does an Older Website Need Accessibility Improvements and When Does It Need a Redesign?

Not every accessibility issue requires a full website redesign.

Isolated issues may be improved through changes such as:

• Colour-contrast adjustments.
• Better alt text.
• Form labels.
• Focus styles.
• Correct button markup.
• Heading corrections.
• Keyboard fixes.

A redesign may be more practical when:

• The entire visual system has poor contrast.
• The navigation architecture is difficult to use.
• Components depend heavily on inaccessible custom interactions.
• The mobile experience is fundamentally weak.
• The content structure is poorly organised.
• Many problems originate from an outdated design system.

If you are unsure which direction is more appropriate, read Website Repair or Redesign? How to Decide in Malaysia.

40. Website Accessibility Checklist for Business Websites

Area	What to Check
Structure	Semantic HTML and logical headings
Images	Meaningful alt text where required
Colour	Sufficient contrast
Information	Do not rely on colour alone
Keyboard	Important functionality works without a mouse
Focus	Visible and not hidden
Touch	Buttons have appropriate size and spacing
Forms	Labels, instructions and errors are clear
Mobile	Zoom, reflow and interactions remain usable
Navigation	Consistent and predictable
Media	Captions and alternatives are considered
Motion	Avoid unnecessary flashing or motion barriers
Custom UI	Modals, tabs, carousels and dropdowns are usable
Testing	Automated + manual + keyboard testing

41. A Quick Accessibility Test Business Owners Can Do Themselves

You do not need specialist software to perform a basic first review.

1. Open your homepage.
2. Do not use the mouse.
3. Press Tab through the navigation and controls.
4. Check whether you can always tell where the focus is.
5. Try opening menus and activating buttons.
6. Test the contact form.
7. Zoom the browser.
8. Open the website on a smartphone.
9. Look for text with weak colour contrast.
10. Ask whether important information would still be available if an image could not be seen.

This is not a complete accessibility audit, but it can reveal obvious barriers quickly.

42. Questions to Ask Your Web Designer or Developer

1. Does the website use semantic HTML?
2. How is the heading hierarchy structured?
3. Can important functionality be used with a keyboard?
4. How are focus states handled?
5. Is colour contrast checked?
6. How are form labels and error messages implemented?
7. Are mobile touch targets tested?
8. How is alt text managed?
9. Are modals, dropdowns and carousels tested with a keyboard?
10. Does accessibility testing include both automated and manual checks?
11. Is the project targeting formal WCAG conformance or general accessibility considerations?
12. If formal conformance is required, who is responsible for validating it?

43. How Can Nibong Web Studio Help?

Nibong Web Studio builds business websites with attention to clear structure, responsive behaviour, forms, navigation and technical foundations.

Within Website Development, relevant considerations can include:

• Responsive page layouts.
• Semantic headings and page structure.
• Clear links and navigation.
• Form validation.
• Image sizing.
• Basic accessibility considerations.

This does not mean that every website automatically includes formal WCAG 2.2 AA certification.

If your project has a specific accessibility requirement arising from a tender, procurement process, organisational policy or internal standard, explain that requirement before quotation so the testing and implementation scope can be defined more accurately.

44. When Might a Website Need a More Specialised Accessibility Assessment?

A specialist accessibility assessment may be more appropriate when:

• WCAG conformance needs to be formally documented.
• The project has a tender requirement.
• The website provides an important public service.
• The website is a complex web application.
• The portal includes authentication and transactional workflows.
• The organisation requires formal accessibility evidence.

In these cases, the scope needs to go beyond standard web-design quality assurance.

Frequently Asked Questions About Website Accessibility in Malaysia

What is website accessibility?

Website accessibility is the practice of making websites easier to access, understand, navigate and use for a wide range of people, including users who rely on assistive technologies or have visual, motor, hearing or cognitive impairments.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is published by W3C and provides testable criteria and guidance for making web content more accessible.

What is the current WCAG version?

WCAG 2.2 is the W3C Recommendation discussed in this guide. It builds on WCAG 2.0 and 2.1 and adds criteria relating to areas such as focus, target size, dragging, authentication and repeated data entry.

What are WCAG Levels A, AA and AAA?

They are WCAG conformance levels. Level A contains baseline success criteria, Level AA adds further requirements and Level AAA includes additional criteria. Formal conformance must be assessed against the applicable WCAG requirements rather than a single accessibility score.

Do all Malaysian websites have to meet WCAG 2.2 AA?

The requirements are not necessarily the same for every private business. Accessibility obligations can depend on the sector, organisation, tender, public-sector requirement or contractual obligations. Obtain appropriate advice if a formal legal or compliance interpretation is required.

Does alt text improve accessibility?

Yes, when an image carries information or functionality that is not otherwise available in text. Alt text should describe the relevant purpose or information rather than being used for keyword stuffing.

Does every image need long alt text?

No. Decorative images may not require descriptive alt text, while complex diagrams may need a more detailed explanation. The right approach depends on the purpose and context of the image.

Is colour contrast important?

Yes. Low contrast can make content difficult to read, particularly for users with low vision or reduced contrast sensitivity. WCAG provides measurable contrast criteria.

Does a website need to work without a mouse?

Important functionality should be keyboard accessible where required by WCAG. This is particularly important for users who cannot operate a pointing device.

Is an accessibility widget enough?

Not necessarily. A widget may offer certain presentation controls, but it does not automatically fix underlying problems such as missing form labels, keyboard traps, poor semantics, focus-management issues or inaccessible custom components.

Is an automated accessibility checker enough?

No. Automated tools are useful but cannot detect every accessibility issue. Manual review and human judgement are still required for many checks.

Is accessibility good for SEO?

Some accessibility practices, such as semantic structure and clear navigation, also align with good web-development and SEO practices. However, accessibility conformance does not guarantee higher Google rankings.

Can an older website be improved for accessibility?

Yes. Many accessibility issues can be improved incrementally. However, a website built on an outdated architecture or a heavily inaccessible component system may require a larger redesign or rebuild.

Should accessibility be planned before the website is built?

It is strongly recommended when accessibility is a project requirement. Colours, components, navigation, forms, media and interactions are generally easier to plan correctly from the beginning than to retrofit after development is complete.

Does Nibong Web Studio provide WCAG certification?

Nibong Web Studio considers basic accessibility within website development, but formal WCAG certification or specialist compliance auditing should not be assumed to be automatically included. If your project has a formal requirement, that scope should be discussed and defined before development begins.

Conclusion

Website accessibility is not simply about adding a button that enlarges text or changes the colour contrast.

It involves the way a website is structured, designed, developed and tested.

For a business website, important areas include:

• Semantic structure.
• Logical headings.
• Meaningful alt text.
• Readable colour contrast.
• Keyboard navigation.
• Visible focus.
• Usable buttons and touch targets.
• Clear forms and error messages.
• Mobile accessibility.
• Captions for relevant video content.
• Predictable navigation.
• Testing that combines automated tools with manual review.

Accessibility should also be treated as an ongoing quality consideration.

A website can become less accessible over time when new content, plugins, components or functionality are added without checking accessibility again.

If you are planning a new website or redesign and want accessibility considerations included from the structure, design and development stages, contact Nibong Web Studio and explain the type of website, target users and any specific accessibility requirements your project needs to meet.