Tips for web accessibility
94 practical tips to help you improve your accessibility
Knowing the issue is the shortest path to the fix
No tips match your search
הצהרת נגישות (17 tips)
Accessibility Barriers
If there are parts of the website or service that are not accessible, state this and explain the reasons, such as technological limitations or exemptions that have been granted.
Accessibility Coordinator Contact Information
Include the name of your organization's accessibility coordinator, along with contact details such as phone number and email address, to enable customers to reach out in case of questions or issues.
Accessibility Issues
Whenever accessibility issues prevent a person with a disability from using your website or receiving your service, inform them of alternative options to access the service. If no such option is available, contact your service accessibility officer for consultation on how to proceed in this case.
Avoid Making Commitments
We do not recommend using mandatory language. For example, instead of "we are committed to," write "we strive to."
Browser and operating system compatibility information
Specify which browsers and operating systems your website is optimally compatible with, so users can know how to get the most accessible experience
Declare your accessibility level and standard
Declare which level your website is accessible at, for example: "The website is accessible at level AA in accordance with WCAG 2.0 guidelines".
Document Your Accessibility Accommodations
Detail the accessibility accommodations that have been implemented on your organization's website and physical location
Information about accessible processes and services
Explain how your services can be used accessibly, including instructions for activating accessibility features on your website, and whether accessible alternatives exist for services that are not fully accessible
Launching a New Website
When you launch a new website, make sure it includes an accessibility statement. Without it, according to Israeli regulations, you could be sued immediately.
Link Placement on the Page
You can add the link to the statement at the bottom of the website. Regulations require that the statement be accessible and placed prominently.
Link to Accessibility Statement
An accessibility statement should appear across all your digital assets on your website, landing pages, and applications if available.
Physical Accessibility Accommodations
Provide detailed information about physical accessibility arrangements such as: accessible parking, accessible routes, elevators, and accessible restrooms
Requesting Feedback
State in your accessibility declaration that if a user encounters a problem, they should provide the following details: 1. Description of the problem 2. What action you were trying to perform 3. Which page were you on? 4. Browser type and version 5. Operating system and version 6. Type of assistive technology used (if applicable). These details will help you locate and resolve the issue
Start with a commitment statement
Open the statement by expressing your organization's commitment to accessibility, equality, and non-discrimination, and emphasize your desire to provide accessible service to all customers.
Technology Accommodations
Provide explanations about the various accommodations you have implemented, such as screen reader support, keyboard navigation, and similar features
Third-party content information
: If your website integrates third-party content or services that are not accessible, disclose this and explain what alternatives are available or how users can get assistance
Update and Date
Indicate the last update date of the accessibility statement, and commit to updating it in accordance with changes or improvements in accessibility
מפתחים (45 tips)
Add alt text to all images
Unless it's purely decorative – in which case, write alt="".
Add aria-labelledby and aria-describedby when needed
If the content is complex, help screen reader users understand what the dialog contains
Add focus indication using CSS
For example: :focus { outline: 2px solid #000; }
Add proper buttons for closing modals
Include aria-label="Close window" for screen reader users.
Align Code Structure with Visual Design
Structure your code to match the visual design from right to left and top to bottom (according to language direction)
Allow closing with both a button and the Escape key
This is part of keyboard accessibility – supporting both methods is required.
Allow popup closure via the Esc key
For the benefit of keyboard users.
Avoid keyboard traps
Don't create components that users can't exit using Tab or Esc. Test to ensure you haven't accidentally created a keyboard trap
Avoid Locking the Viewport
Don't use <meta name="viewport" content="user-scalable=no"> – it blocks zooming.
Avoid pop-ups that block navigation
Ensure they can be closed or exited with Esc or a clear button.
Build buttons with <button> instead of <div> or <a> alone
This way you'll get all the built-in accessibility functionality.
Display form errors accessibly
Use clear text and indicate the problematic field (using aria-describedby).
Don't rely on color alone to convey status
Use an additional icon or text: "Required field", "Error".
Enable form submission with Enter key, not just mouse clicks
Especially for forms or form-like components.
Enable full keyboard navigation within popups
Including navigation, selection, and closing – without requiring a mouse.
Ensure dialog content includes a clear heading
It's advisable to have a prominent heading at the top of the dialog, with a concise description of its purpose.
Ensure dropdown menus respond to keyboard controls
Tab, Enter, Esc, arrow keys – all should work.
Ensure every interactive element can be operated by keyboard alone
Don't rely solely on onclick events – add onkeydown as well.
Ensure focus moves to the popup when it opens
This allows keyboard users to navigate through it easily.
Ensure navigation order is preserved in responsive design
For example: a phone field should not appear before a first name field on mobile.
Ensure popups are accessible on small screens
Responsiveness and accessibility go hand in hand.
Ensure proper use of heading tags (H1-H6)
Only one H1 is allowed per page. Maintain a logical hierarchy.
Ensure screen readers recognize when a dialog opens
When a dialog opens, update aria-hidden on the background and automatically focus the dialog.
Ensure users know when a modal dialog opens
Use <code>aria-hidden</code> and <code>aria-modal="true"</code>.
Hover States
Use :focus-within to create an accessible alternative to hover states
Keep focus trapped within the dialog
When the dialog is open, the user should remain within it – without jumping to elements outside. If you're using the <dialog> tag, you don't need to worry; the tag handles this for you.
Keyboard Focus Styles
Use :focus-visible to customize focus styles for keyboard users without disrupting the experience for mouse users
Maintain a clear visual hierarchy within popups
Title, content, action – in a clear order.
Maintain a logical and natural tab order
Avoid using tabindex values greater than 0 unless absolutely necessary.
Maintain Color Contrast According to Requirements
A contrast ratio of at least 4.5:1 for regular text, and 3:1 for large text or provide a mechanism that handles it
Make touch targets accessible on small screens
At least 44px height and width.
Return focus to the trigger element when a popup closes
This maintains proper action sequence.
Support both touch and keyboard navigation
Support both hover and focus states.
Test compatibility with older browsers
<dialog> is not fully supported in all browsers – consider a fallback or polyfill if needed.
Trap focus within modals and popups
Prevent tab navigation from moving outside the active window.
Update dynamic descriptions using live regions
For example <div aria-live="polite"> – suitable for notifications like "saved successfully".
Use .showModal() for proper dialog opening
This sets the dialog as modal (blocking background) and automatically transfers focus to it
Use <form method="dialog"> for action buttons within dialogs
This action will close the dialog automatically – convenient and safe.
Use ARIA only when there's no semantic alternative
For example, role="button" only when you can't use a <button> element.
Use aria-modal and aria-labelledby or aria-label for popups
So screen readers understand what is being displayed.
Use autocomplete in form fields
For example: autocomplete="email", name, tel.
Use HTML5 semantic tags for site structure
For example <header>, <main>, <nav>, <section>, <footer> – they help screen readers understand the page structure.
Use labels in forms
Every input field needs a <label for="id"> that matches the element's id attribute.
Use rem or em units for text and spacing sizes
Avoid hardcoded px – to enable text resizing.
Use the <dialog> element
Instead of using a DIV for pop-ups, use the <dialog> element. It comes accessible out of the box and will save you a lot of accessibility work.
עיצוב (32 tips)
Always pair icons with text labels
Even if the icon is recognizable (such as a pencil for editing), add a label or explanatory text
Avoid excessively long line lengths in text
Up to 80 characters per line in responsive text – helps readability
Avoid Flashing or Moving Content
Flashing elements (especially more than three times per second) can trigger sensitivities and neurological harm.
Clear heading hierarchy
Use headings in a logical order (H1, H2, H3, etc.) based on document structure, not just for visual styling.
Consistent use of design elements
Styles, buttons, menus and icons should look and behave the same way across all pages
Don't rely on color alone to convey information
Add text, icons, or patterns to distinguish between elements, for example in forms with errors.
Enable toggling between dark and light modes
Some users are sensitive to bright light – a dark interface can help
Ensure Adequate Touch Target Sizes
Touch targets on mobile should be at least 44x44 pixels in size
Ensure rich media is accompanied by alternative text
Videos should include captions. Audio elements should have text descriptions.
Ensure sufficient contrast for non-text interface elements
Such as form field borders or active states – color contrast is critical
Ensure your interface is usable without a mouse
Designers should consider how the interface looks and functions when navigating by keyboard alone – this is critical for many users
Keep button labels concise
A button should be brief — use a few words that clearly describe the action
Maintain a minimum text size of 16 pixels
Especially for body text – to ensure readability across responsive layouts.
Maintain adequate spacing between lines and text
A recommended line height of at least 1.5, and paragraph spacing of at least 1.5 times the line height.
Maintain High Contrast
Ensure sufficient color contrast between text and background (per WCAG Level AA – a ratio of at least 4.5:1 for normal text).
Maintain logical order in layout and reading flow
For example: menus on the left side, heading at the top, form in the middle, submit button at the end – according to the design language.
Maintain visual hierarchy with clear distinction between components
Users need to understand what is primary, what is secondary, and what is auxiliary
Make all design functions keyboard accessible
Include dropdowns, tabs, hidden buttons, and more.
Prefer simple and clear designs
"Clean" interfaces with plenty of white space help reduce cognitive load.
Provide accessibility adjustments without hiding or degrading content
Adjustments like changing contrast or enlarging text should be available without sacrificing functionality
Provide clear indicators for interactive component states
For example: selected state, completed form, active tab, current step in a process.
Provide Explanations
Provide explanations to developers about the functionality you are planning
Provide Titles and Descriptions for Every Link
Text like "click here" is not sufficient – write "read more about our service", for example.
Provide visual and sensory feedback for actions
For example, changing button color on mouse hover, keyboard focus indicators, audio or visual alerts after submission.
Test your design across different zoom levels and personalization settings
Ensure your design remains readable and navigable even with text enlargement, high contrast mode, or RTL languages like Hebrew
Test your design for color blindness compatibility
There are tools that simulate color blindness – it's important to test elements that rely on color in particular.
Text can be enlarged without breaking the layout
Ensure that the design maintains its structure even when text is enlarged up to 200%.
Touch Target Size
It is very important to create a visible border that shows the touch target area of buttons
Use clear focus indicators
When a user navigates between items using the keyboard – it's important to clearly see which element is active.
Use live text instead of text embedded in images
Text should be copyable, resizable, and readable by screen readers – avoid embedding text within images
Use readable and accessible fonts
Avoid ornate or decorative fonts for body text, and prefer simple sans-serif fonts (for example, Arial, Open Sans).
Using Forms with Clear Labels
Every form field should include a clear label with appropriate indication for error status, required fields, or valid input.
Did not find what you were looking for?
Our expert team is happy to help
Want us to audit your site?
A professional audit that shows exactly what to fix