1️⃣ Conference | National conference on disability (CNH) - French Government

The French National Conference on Disability (Conférence nationale du handicap – CNH) is a major national event dedicated to shaping public policy around disability and inclusion in France. Held every three years under the authority of the President of the French Republic, the conference brings together people with disabilities and their representative organisations, associations, public authorities, social partners, and other stakeholders. Accessibility is one of the areas addressed by the CNH, alongside employment, education, health, housing, mobility, access to information and communication, and participation in civic life.

📅 Date: September 4, 2026

Learn more about the CNH

2️⃣ Job opportunity | Digital accessibility auditor - Taylor & Francis

Taylor & Francis is looking for a Digital Accessibility Auditor to join its central Accessibility team in London. The role focuses on conducting detailed manual accessibility testing of websites and digital platforms against WCAG 2.1 and 2.2, identifying accessibility barriers, preparing conformance documentation and accessibility statements, and providing actionable recommendations to product and development teams. Candidates should have professional experience with accessibility audits, assistive technologies, screen readers, keyboard navigation, accessibility testing tools, WCAG, ARIA, and basic HTML, CSS, and JavaScript knowledge. This is a 12-month fixed-term contract or internal secondment, with a hybrid working model.

📍 Location: Hybrid - London, UK

Apply for this job

3️⃣ Conference | Inclusive design 24 (#id24) 2026

Inclusive Design 24 (#id24) is returning on September 24, 2026 with another free 24-hour online event for the global inclusive design and accessibility community. The programme covers topics ranging from digital accessibility and assistive technology to accessible documents, inclusive research, neuro-inclusive design, WCAG 3, design ethics, and accessibility in the age of AI. There is no registration or sign-up required. Sessions are streamed live publicly, and all sessions include automated live captions, which are replaced by manually edited captions after the event.

📅 Date: September 24, 2026

Participate in the conference

Read more

• ✅ Correct HTML

• ✅ ARIA

• ✅ Keyboard support

• ✅ No critical issues in automated tests

- and still leave users frustrated.

There is a difference between being accessible on paper and being truly accessible in real life.

Here are five examples of how it works:

1. “Skip to content” link exists, but the user still has to work hard to find anything

The page technically has headings and a skip link, but the screen reader user encounters navigation, cookie banners, ads, duplicated menus and dozens of controls before understanding where they are. It might be accessible, but not easy to use.

WCAG 2.4.6 Headings and Labels

WCAG 2.4.1 Bypass Blocks

2. The checkout works perfectly with a keyboard after 100 Tab presses

Every element is reachable, nothing is technically broken, but can a user efficiently reach the “Pay” button? Keyboard accessibility shouldn’t only mean: “Can I reach it eventually?”, it should mean “Can I use it without exhausting myself?”

WCAG 2.1.1 Keyboard

WCAG 2.4.3 Focus Order

3. “Error. Invalid input.”

The error is announced by the screen reader, except the user has no idea what is wrong. Is the password too short? Is the date incorrect? Which format should they use? It is an error message that doesn’t help you fix the problem.

WCAG 3.3.1 Error Identification

WCAG 3.3.3 Error Suggestion

4. Alternative text: “Woman”

Yes, the image has alt text, but imagine an online shop where every product image is announced as: “Woman. Bracelet. Bag.” Or an important chart that is described as: “Graph”. The attribute exists, but the information doesn’t.

WCAG 1.1.1 Non-text Content

5. “This video has captions.”

It is great to have them, except if the captions are: inaccurate, delayed, too fast, missing speakers Technically, captions exist, but can a user actually follow the video?

WCAG 1.2.2 Captions (Prerecorded)

WCAG is essential, automated testing is useful, accessibility audits matter, but they are not the finish line. It is important to remember that people don’t experience websites as success criteria and ask questions like this one: “Can a real person actually use this independently, efficiently and confidently?”

#Accessibility #WebAccessibility #WCAG #A11y #DigitalAccessibility #InclusiveDesign

• a confusing focus order

• focus disappearing behind a sticky header

• dozens of unnecessary Tab stops

• controls that don’t behave as expected

• no clear indication of where you are

WCAG 2.2 addresses both logical focus order and focus being obscured by author-created content.

Which accessibility myth have you heard repeated the most? 👇

Visually, these can look identical, but semantically, they are not.

✅ If you only want to change how text looks → use CSS.

<p>This is <span class=”bold”>important</span>.</p>

.bold {

font-weight: 700;

}

✅ If the text has strong importance or seriousness → use <strong>.

<p><strong>Do not share your password.</strong></p>

The difference matters because HTML communicates the meaning and structure of content to browsers and assistive technologies.

Other reasons why it is important:

• <strong> carries semantic meaning

• CSS font-weight changes presentation, not meaning

• assistive technologies can expose semantic emphasis differently depending on the technology and user settings

• removing CSS should not remove the meaning of important content

• semantic HTML gives other technologies more information to work with

Here are some interesting facts:

• <strong> doesn’t simply mean “make this bold” - its meaning is strong importance, not a visual instruction

• <b> and <strong> are not interchangeable: <b> draws attention without adding the same semantic importance as <strong>

• you don’t need to make <strong> visually bold. CSS can style it however you want - the semantic meaning remains

• you can have <strong> inside a sentence, you don’t need to wrap an entire paragraph in it

• nesting matters: <strong><strong>Very important</strong></strong> doesn’t magically make something “twice as important”

• bold-looking text isn’t necessarily important text: a navigation label, product name or visual heading might be bold simply because of the design.

• screen readers don’t necessarily announce every <strong> as “bold” or “important”. The exact experience depends on the screen reader and its settings.

• <em> is also semantic. It represents emphasis, while <strong> represents strong importance. Neither is simply a replacement for font-style: italic or font-weight: bold.

Here’s a practical checklist on using <strong> versus bold:

• You only want text to look bold → use CSS font-weight

• The text is strongly important → use <strong>

• You want to draw attention without adding importance → consider <b> or appropriate styling

• The meaning is emphasis → use <em>

• You’re making a heading → use the appropriate <h1>–<h6>, not bold text

• You’re making a list → use <ul>, <ol> and <li>, not bold lines with bullets

• You’re making a button → use <button>, not a bold <span>

HTML isn’t decoration, the elements you choose tell the browser not only what your content should look like, but also what it means.

What’s another HTML element that you find developers often use for its appearance instead of its meaning?

Here are 10 things about keyboard navigation that even people who build websites sometimes overlook:

1. Tab doesn’t mean “move to the next thing I can see”

   Keyboard focus generally follows the order of elements in the HTML/DOM, not their visual position on the screen. So CSS can make a page look perfectly ordered while keyboard focus moves through it differently.

2. Tab is only one part of keyboard navigation

   Inside components such as tabs, menus and grids, arrow keys may move between items, while Enter, Space, Home, End or Escape can have specific roles. Accessible keyboard interaction is about following the expected interaction pattern for the component.

3. A keyboard trap can make an entire website effectively unusable

   Focus can enter a component but, because of poor implementation, become impossible to move away from using the keyboard. The mouse still works, the page still looks fine, but the keyboard user is stuck.

4. tabindex=”0” doesn’t turn a <div> into a button

   It makes the element focusable. It doesn’t give it the semantics or keyboard behaviour of a button. This is one of those cases where “keyboard accessible” and “actually accessible” are very different things.

5. A component can be visually first but keyboard-later

   CSS properties such as order can rearrange content visually without changing its underlying DOM order. The screen says “start here”, but the keyboard may say something else.

6. Focus can move somewhere you can’t see

   A sticky header, footer, cookie banner or modal can cover the element that currently has keyboard focus. The focus hasn’t disappeared - it has simply become obscured.

7. Removing the focus outline can remove someone’s sense of location

   For a sighted keyboard user, focus is a navigation signal. Without a visible focus indicator, they may know what they just did but have no idea where they are now.

8. tabindex=”-1” doesn’t mean “not accessible”

   It means the element isn’t in the normal Tab sequence, but it can receive focus programmatically. This is extremely useful for things like moving focus to a newly opened dialog or a heading after navigation.

9. Native HTML gives you keyboard behaviour for free

   A real <button>, <input>, <select> or link already comes with browser-supported interaction behaviour. Rebuilding the same thing with a <div> means you may have to recreate that behaviour yourself correctly. That’s a lot of responsibility for something that could have been a button.

10. Everything being reachable doesn’t mean the experience is good

    A page can technically work with a keyboard and still require dozens of Tab presses, have a confusing focus order, or make the user hunt for where focus went.

If it is the main topic or purpose of the page → use <h1>.

For example: for a homepage it would be a heading that describes the main purpose of the website.

Why does this matter?

• Screen reader users can navigate through headings instead of reading every word on the page.

• A heading gives users a quick way to understand the structure of the content.

• The H1 can help confirm that they have arrived at the page they expected.

• Headings are not just visual decoration. They are part of the information structure.

Here are a few interesting facts:

• An H1 does NOT have to be the biggest text on the page. The visual appearance is a CSS decision. The HTML element communicates meaning.

• “Exactly one H1 per page” is not a WCAG requirement. This is one of the most common accessibility myths. What matters is that headings and labels describe the topic or purpose of the content and that the information structure is meaningful.

• A page can look perfectly structured and still have a terrible heading structure. For example, a designer may create beautiful visual headings while developers use , or other elements instead of actual heading elements. To a sighted user, everything may look fine, while to someone navigating by headings, the structure can be completely different.

• Heading level is not about font size. An can be visually larger than an <h1>. That’s not necessarily a problem. The important question is: what is the heading’s role in the content structure?

• More headings are not automatically better. A page full of headings doesn’t become more accessible just because it contains lots of , and elements. The headings should reflect the actual organization of the content.

What does WCAG say?

WCAG 2.2 Success Criterion 1.3.1 “Info and Relationships” requires relationships and structure conveyed through presentation to be programmatically determinable. And SC 2.4.6 “Headings and Labels” requires headings and labels to describe topic or purpose.

So it is not correct to think: “I need one H1 because WCAG says so”.

Instead an approach should be: “I need a meaningful main heading because people need to understand what this page is about”.

Web accessibility H1 checklist:

• ✅ Is the main topic or purpose of the page clear?

• ✅ Is there a meaningful heading identifying it?

• ✅ Is it marked up as a semantic heading?

• ✅ Does the H1 actually describe the page?

• ✅ Are the other headings meaningful and logically organized?

• ✅ Are headings being used for structure rather than simply for visual styling?

There are several things happening between the moment we design something and the moment someone actually sees it:

1. Compression can change the result

   Images uploaded to social platforms are often compressed. Colors can shift slightly, edges can become softer, and text can lose definition. If your contrast was already close to 4.5:1, that margin can disappear.

2. Resizing changes readability

   A large graphic may look perfectly readable on your screen. Then the platform displays it at a smaller size. Text becomes smaller, strokes become thinner and edges get softened by scaling. The colors haven’t necessarily changed, but the perceived contrast can.

3. Thin fonts + antialiasing matter

   Contrast tools usually calculate the ratio between the defined foreground and background colors. But that’s not exactly what every pixel on the screen looks like. With antialiasing, edge pixels are blended between the text and the background. Thin fonts therefore contain many pixels that are neither the original text color nor the original background color. This is one reason why 4.5:1 with thin text can feel very different from 4.5:1 with a heavier typeface.

4. The screen isn’t a controlled environment

   People might view the same content:

   -☀️ in bright daylight

   -📱 on different phones

   -🔆 at different brightness levels

   -🖥️ on different displays

   -👓 with or without corrective lenses

   A design that is just barely readable in your design environment may not be equally robust everywhere.

5. Check the final rendered version

   If you’re designing an image for social media, don’t only check the colors in Figma, Sketch or your design tool. Check the actual image after export, upload and resizing. If possible, take a screenshot of the final rendered version and measure that. You’re then testing the pixels users are actually seeing, not just the colors you originally specified.

Here’s a good practical color contrast checklist:

• ✅ Check the foreground/background contrast before exporting

• ✅ Don’t design right on the minimum 4.5:1 threshold - leave some margin

• ✅ Avoid relying on very thin font weights for important text

• ✅ Check text at the actual size users will see it

• ✅ Test the exported image, not only the source file

• ✅ If a platform resizes/compresses the image, check the result afterwards

• ✅ Test text over gradients, images and textured backgrounds at its weakest point

• ✅ Check important UI states separately: default, hover, focus, active, disabled and error

• ✅ Look at the design on more than one display and under realistic lighting

• ✅ Don’t rely only on a contrast checker - visually inspect the result too

WCAG gives us important minimum thresholds: 4.5:1 for normal text at AA, 7:1 at AAA, and 3:1 for relevant non-text elements. These thresholds are essential for conformance, but they don’t describe the entire visual experience.

Here are 3 things I think we need consider beyond the number:

1. Contrast ratio is a minimum, not a design target

   If 4.5:1 passes, that doesn’t mean 4.5:1 is the best choice. Greater luminance separation can make interfaces more resilient across different displays, lighting conditions, text sizes, and individual visual differences.

2. Highly saturated colors can behave badly together

   Certain combinations of strong, saturated hues can create a visual “vibration”: edges may appear unstable, shimmer, or become harder to focus on. Some chromatic contrasts can also produce a perception of blur or instability at boundaries. This is related to the way our visual system processes different wavelengths. So a pair of colors can have a technically acceptable contrast ratio and still be uncomfortable to look at.

3. Color is perceived in context

   Josef Albers’ Interaction of Color is a great reminder that we don’t perceive colors independently. The Bezold Effect demonstrates how changing one color in a composition can alter the perceived appearance of surrounding colors.

The same text color can therefore feel completely different depending on its background and neighboring colors. For digital interfaces, this means a color shouldn’t only be tested in a contrast checker - look at it in context.

Here’s a practical color accessibility checklist:

• Check WCAG contrast ratios

• Don’t automatically design to the minimum threshold

• Check highly saturated color combinations for visual “vibration”

• Evaluate thin and small text more critically than large text

• Look at colors in their actual UI context, not in isolation

• Check text against its real background, including gradients and images

• Make sure meaning isn’t communicated by color alone

• Test important states such as hover, focus, error and disabled

• Review the interface under different lighting and display conditions

One important thing to keep in mind: a contrast checker measures a relationship between colors, but it doesn’t measure the entire human experience of looking at them. Remember that WCAG compliance is the baseline.

1️⃣ Workshop | Accessibility in Technology Procurement and Use – WebAIM

Accessibility needs to be considered before a new technology is purchased, not only after it has been implemented. This virtual workshop from WebAIM explores how organizations can integrate accessibility into procurement and technology decision-making.

Participants will learn how to evaluate products and vendors, work with VPATs and Accessibility Conformance Reports, include accessibility requirements in procurement processes, and better assess third-party technologies before they become part of an organization’s digital environment.

📅 Date: August 20, 2026

Register for this workshop

2️⃣ Public Tender | UX/UI Design and Digital Accessibility (RGAA) – Département de la Seine-Maritime

The Département de la Seine-Maritime has launched a public procurement opportunity covering UX design, UI design, and digital accessibility.

The framework agreement includes support for designing the ergonomics and visual interfaces of web and mobile applications, as well as accessibility compliance audits based on the French RGAA accessibility framework. The contract can run for up to four years and has an annual maximum value of €80,000 excluding VAT.

This could be particularly relevant for agencies, consultancies, and accessibility professionals with experience in UX, UI, web accessibility audits, and RGAA compliance.

📅 Deadline: September 15, 2026

Apply for this tender

3️⃣ Job Opportunity | Senior Digital Expert – Integer Consulting

Integer Consulting is looking for Senior Digital Experts for a hybrid project in Lisbon. The role is aimed at experienced professionals with backgrounds in digital accessibility, SEO, content strategy, content organization, or migration.

For accessibility-focused candidates, the position requires strong knowledge of WCAG standards and accessibility audit tools, alongside an analytical mindset and the ability to work independently.

📍 Location: Hybrid – Lisbon, Portugal

Apply for this job

Read more

In the beginning, I used to think that the best response was to explain all the different barriers that people with disabilities can face online or talk about situational disabilities. But lately I try another approach: there is one thing none of us can avoid - we are getting older and, as we age, our abilities can change.

• Our eyesight may not be quite what it was. Small text can become harder to read, and low contrast can become much more tiring.

• Our hearing can change too. Following a video with background noise or understanding information that is provided only through audio can become more difficult.

• Fine motor control can change, making tiny buttons or precise interactions more frustrating.

• And sometimes we simply need more time to process information, remember where we are on a website, or figure out what a complicated interface is asking us to do.

Of course, this doesn’t mean that everyone who gets older will experience all of these changes - ageing is different for everyone.

But it does mean something important: our abilities aren’t fixed.

Accessibility isn’t about designing a special version of the web for “people with disabilities” or “old people”, instead it is about making the web work for people with different abilities, in different situations, at different moments in their lives.

You probably already benefit from accessible design, here are some examples:

• Using captions while watching a video.

• Increasing the text size because you’re tired.

• Struggling to tap a tiny button.

• Using voice input because your hands are busy.

Here are some interesting facts to think about:

• By 2030, 1 in 6 people in the world will be 60 or older. By 2050, that number is expected to reach around 2.1 billion people.

• Age-related changes in vision can include reduced contrast sensitivity, changes in colour perception and difficulty focusing on things close up - all of which can affect how someone experiences a website.

• In the WHO European Region, around 190 million people live with hearing loss or deafness.

• More than 2.5 billion people worldwide need one or more assistive products today. The WHO estimates that this could rise to 3.5 billion by 2050.

Accessibility is not something we do for other people. We are designing for people who have different needs from us today and we are also designing for ourselves tomorrow.

<a href=/__u/a11ywithdiana.substack.com/&#8221;/home&#8221;%3E%3Ci class=”icon-home”></i></a>

Visually, everyone understands it: 🏠 → Home

But the browser doesn’t magically know that icon-home means “Home”. That class name exists for your CSS and icon library. It doesn’t automatically become the accessible name of the link.

Here’s a simple rule that I use:

🔗 If an icon is the only content of a link → the link needs an accessible name.

🔘 If an icon is the only content of a button → the button needs an accessible name.

For example:

❌Bad example:

<a href=/__u/a11ywithdiana.substack.com/&#8221;/home&#8221;%3E%3Ci class=”icon-home”></i></a>

✅ Good example:

<a href=/__u/a11ywithdiana.substack.com/&#8221;/home&#8221; aria-label=”Home”><i class=”icon-home” aria-hidden=”true”></i></a>

But sometimes the icon shouldn’t be announced at all.

If we have a code:

<a href=/__u/a11ywithdiana.substack.com/&#8221;/home&#8221;%3E%3Ci class=”icon-home”></i>Home</a>

Its visible word “Home” already tells the user what the link does and the icon is decorative.

✅ It should be:

<a href=/__u/a11ywithdiana.substack.com/&#8221;/home&#8221;%3E%3Ci class=”icon-home” aria-hidden=”true”></i>Home</a>

So the goal isn’t to give every icon an accessible name - it is to make sure the interactive element has the right accessible name.

A few facts that surprise many developers:

• icon-home is a CSS class, not an accessible description.

• an icon created with ::before or ::after can look perfect while the actual button or link still has no useful name.

• a tooltip isn’t a replacement for an accessible name.

• the same icon can be decorative in one place and essential in another.

• icon + visible text → icon is probably decorative.

• icon alone → the control needs to communicate its purpose another way.

• aria-hidden=”true” is useful for decorative icons, but hiding the only meaningful content of a control creates the opposite problem.

• icon-only controls can be especially problematic in toolbars.

So visually icons might seem obvious, but a screen reader user might encounter: “Button. Button. Button.” Compare that with: “Edit button. Delete button. Copy button.” Same interface can provide a completely different experience.

Here’s a practical icon accessibility checklist:

• Icon-only link → Give the link an accessible name

• Icon-only button → Give the button an accessible name

• Icon + visible text → Hide the decorative icon when appropriate

• Icon font / <i> element → Don’t assume the class name provides meaning

• CSS pseudo-element icon → Check the actual accessible name

• Tooltip → Don’t rely on it as the only mechanism

• Toggle icon → Make sure its current state is communicated

Visual meaning isn’t automatically semantic meaning.

What icon pattern do you see most often causing accessibility problems?

Here are some encouraging numbers (the percentages represent the share of participating companies that have each practice in place):

• 95% report universally designed digital assistive supports, such as captions, transcription and audio descriptions.

• 98% provide flexible or remote work accommodations.

• 95% report universally designed physical supports.

But the picture changes when we look at accountability:

• Only 48% require suppliers to meet physical and digital accessibility requirements.

• Only 47% have a formal process to remediate accessibility issues originating from suppliers.

• Only 31% include workforce disability representation in annual reports.

And EMEA (Europe, the Middle East and Africa) shows an especially interesting gap: while the region performs relatively well in disability-related reporting, only 50% of companies report having resources dedicated to resolving accessibility and compatibility issues for customers using public-facing digital products and content, compared with 74% globally. Only 56% provide instructions for requesting accommodations through public-facing recruitment websites, compared with 77% globally.

I think it highlights an important accessibility maturity issue: having accessible tools is not the same as having accessibility embedded into an organisation. If accessibility is considered only after a product is purchased, a website is launched or a customer reports a barrier - we’re already too late.

Organisations can take some practical steps:

• Include accessibility requirements in procurement and vendor selection.

• Assign clear ownership and resources for resolving digital accessibility issues.

• Measure remediation and user outcomes, not just compliance.

• Build accessibility into recruitment, design, development and content processes from the start.

• Make accessibility part of organisational accountability, not something owned exclusively by the accessibility team.

The next step in accessibility maturity is building organisations that are structurally capable of creating and maintaining accessible digital experiences.

What stood out to me was not the ranking itself, but what can be missed when we rely too heavily on automated testing and accessibility scores.

Automated tools are incredibly useful, but they cannot fully tell us what it is like to actually navigate and use a website - that’s why human accessibility testing still matters.

For me, the goal of accessibility should never be to be “in the top 5%” - it should be to make the web genuinely more accessible to the people who use it.

I recorded a my audit to share what I found and why I think we need to look beyond the numbers, here is a link to the full video:

I’d love to hear your thoughts: do you agree with WebAIM that this webpage stands in top 5% of accessible webpages?

Despite the name, screen readers don’t analyse pixels. They read information from the browser’s accessibility tree, which is built from HTML semantics, accessibility APIs and ARIA. If information isn’t exposed there, it may not exist for a screen reader user.

2️⃣ Experienced users listen at more than 400 words per minute.

To someone hearing it for the first time, it sounds almost incomprehensible. But experienced users become remarkably efficient at understanding highly accelerated speech, allowing them to navigate websites much faster than many sighted users.

3️⃣ A screen reader can tell whether it is a button, even if it doesn’t look like one.

And the opposite is also true. A beautiful element that looks like a button but is built from a <div> without the correct semantics may be announced simply as “clickable” or even as plain text.

4️⃣ Users rarely listen to a page from top to bottom.

Instead, they jump between headings, landmarks, links, form controls and regions. Think of it as using Ctrl+F on an entire website, except the navigation relies on your HTML structure.

5️⃣ A list of links can instantly expose poor link text.

Most screen readers let users display every link on a page. Imagine seeing a list that says: read more, click here, learn more, more... Without surrounding context, those links become almost meaningless.

6️⃣ Emoji have names and screen readers read them aloud.

A single 😊 becomes “smiling face with smiling eyes.” A long chain of decorative emoji can turn one short sentence into a surprisingly long listening experience.

7️⃣ Screen readers announce information most people never see.

They can tell users whether a checkbox is checked, whether a button is expanded, whether a field is required, whether a heading is level 2, whether a menu item has a submenu, or whether an image has alternative text.

8️⃣ Bad ARIA can make a website less accessible than having no ARIA at all.

This is why accessibility professionals often repeat the first rule of ARIA: No ARIA is better than bad ARIA. Native HTML already provides much of the accessibility information browsers and assistive technologies need.

9️⃣ A website can look perfect and still be almost unusable with a screen reader.

Visual design and accessibility are largely independent. Two pages that appear identical can provide completely different experiences depending on their underlying HTML and accessibility semantics.

🔟 The biggest accessibility improvement is often invisible.

Users may never notice whether you’ve added semantic headings, associated labels, landmarks or proper button elements, but screen reader users almost certainly will. Some of the most impactful accessibility work cannot be seen at all.

1️⃣ Conference | The 11th World Disability and Rehabilitation Conference 2026

The 11th World Disability and Rehabilitation Conference (WDRC 2026) brings together researchers, practitioners, policymakers, healthcare professionals, disability advocates, and accessibility experts to discuss the latest developments in disability inclusion, rehabilitation, assistive technologies, inclusive education, healthcare, employment, and digital accessibility. The conference offers an excellent opportunity to exchange research, discover innovative solutions, and connect with professionals working to improve accessibility worldwide.

📅 Dates: August 10 - 11, 2026

Apply to participate in this conference

2️⃣ Public Tender | Giubileo 2025 S.p.A. – Helpdesk & Digital Support Services

Giubileo 2025 S.p.A. has launched an open public procurement for helpdesk services, cybersecurity support, and related software licensing. While the procurement focuses primarily on IT support services, it presents an opportunity for suppliers experienced in delivering accessible digital support environments, inclusive service desks, and user-centered technical assistance within large public-sector projects.

📅 Submission deadline: September 15, 2026

Apply to get this public tender

3️⃣ Job Opportunity | Digital Accessibility Consultant – KEYTEO

KEYTEO is recruiting a Digital Accessibility Consultant in Luxembourg to help organizations improve the accessibility of web and mobile applications. The role includes analyzing user journeys, identifying accessibility barriers, preparing remediation recommendations, collaborating with UX, development, QA, and product teams, and evaluating compliance with WCAG using assistive technologies such as NVDA. Previous experience in regulated sectors is considered an advantage.

📍 Location: Luxembourg

Apply for this job

Read more

• 🟣 #7755ff and #9944ff

• 🔵 #4466ff and #2277cc

• 🟢 #008855 and #118833

• 🟠 #cc4455 and #dd3333

• 🔴 #ee0000 and #dd3300

Behind the scenes, it’s all about relative luminance: to achieve a contrast ratio of 4.5:1 against both white (L = 1) and black (L = 0), a color’s relative luminance must fall between 0.175 and 0.183. That’s an incredibly small range, which explains why there are only a handful of colors that work well on both backgrounds.

Choosing colors that are compliant on both white and black backgrounds can make it much easier to build components that work consistently in both light and dark themes without sacrificing readability. It can also reduce the number of color variations that need to be designed, tested and maintained.

Here are a few interesting facts:

• 💡 The theoretical maximum contrast a single color can achieve against both black and white is only about 4.58:1, barely above the WCAG AA requirement of 4.5:1.

• 💡 Two colors that look almost identical can have completely different contrast ratios because accessibility is based on relative luminance, not on how bright a color appears to our eyes.

• 💡 Passing the 4.5:1 ratio doesn’t automatically make a design accessible. Font size, font weight, spacing, surrounding colors and focus indicators all play an important role.

• 💡 Color should never be the only way to communicate information. Error messages, required fields, selected items and status indicators should always have another visual cue in addition to color.

Practical checklist for color contrast:

• ✅ Check text contrast before implementation.

• ✅ Test your colors on both light and dark backgrounds.

• ✅ Don’t rely on visual judgment; use a contrast checker.

• ✅ Don’t use color alone to convey meaning.

• ✅ Verify hover, focus, disabled and visited states, not just the default state.

• ✅ Test your interface with real users if possible.

One final thought: 4.5:1 is the minimum required by WCAG, not the ideal target. Whenever possible, aim for higher contrast. Real-world conditions such as screen brightness, sunlight, font rendering, font weight or overlays can all reduce perceived contrast, so designing with a margin helps create a more accessible experience.

Here’s a useful rule:

1. If nobody should see or interact with the content, use “display: none” (or the “hidden” attribute).

Examples:

• ➡️ a modal before it’s opened.

• ➡️ a collapsed accordion panel.

• ➡️ a loading indicator that’s no longer needed.

2. If the content should stay visible but be ignored by assistive technologies, use aria-hidden=”true”.

Examples:

• ➡️ a decorative icon next to a button label.

• ➡️ a visual separator.

• ➡️ an illustration that doesn’t provide additional information.

It matters because browsers expose web pages through something called the accessibility tree:

• ”display: none” removes an element from both the page and the accessibility tree.

• ”aria-hidden=”true”“ only removes it from the accessibility tree - it stays visible on screen.

• if you hide meaningful information with aria-hidden, screen reader users may never know it exists.

• if you hide a focusable element with aria-hidden, you create an experience that can be confusing or even impossible to use.

Some interesting facts about the difference between display: none and aria-hidden=”true”:

• “display: none”, “visibility: hidden” and the HTML “hidden” attribute all remove content from the accessibility tree.

• aria-hidden does not visually hide anything.

• aria-hidden=”true” should never be used on focusable elements or on a parent that contains focusable elements.

• before adding ARIA, ask yourself whether semantic HTML already solves the problem.

Here’s a useful checklist that can help:

• ✅ Nobody should see it → “display: none” or “hidden”

• ✅ Decorative content → aria-hidden=”true”

• ✅ Duplicate visual content → aria-hidden=”true” (when appropriate)

• ❌ Important information → don’t hide it from assistive technologies

• ❌ Buttons, links or form controls → never use “aria-hidden=”true”“ on focusable elements

It’s important to remember that you’re not just building the DOM - you’re building the accessibility tree as well and if you’ve never explored the accessibility tree in your browser’s developer tools, it’s well worth doing as it often explains accessibility bugs much faster than reading the HTML.

Have you ever found an accessibility issue that was actually caused by content being hidden the wrong way?

On the positive side, I appreciate that organizations are recognizing that accessibility goes beyond running automated scans of websites. Roles today include knowledge of accessibility standards, assistive technologies, accessibility testing, front-end development, UX, design systems, training and collaborating with people with disabilities. This demonstrates an appreciation for the role of accessibility across the product lifecycle.

But lately, I’ve noticed that some of the job descriptions for these positions contain responsibilities from multiple positions. One person is expected to:

• ✅ Audit websites, PDFs, mobile apps, and multimedia.

• ✅ Know WCAG, EN 301 549, Section 508, and the ADA inside out.

• ✅ Build accessible React applications.

• ✅ Understand HTML, CSS, JavaScript, ARIA, accessibility APIs, and design systems.

• ✅ Test with NVDA, JAWS, VoiceOver, TalkBack, keyboard navigation, and automated tools.

• ✅ Train designers, developers, QA teams, and product managers.

• ✅ Work directly with people with disabilities.

• ✅ Define accessibility strategy, influence leadership, create documentation, and even contribute to standards.

That is an impressive skill set for one person. Nevertheless, such a skill set is an enormous expectation of one person to master.

Accessibility is multidisciplinary in its approach. While it’s good to have specialists with a broad range of knowledge within that area, long-term success can only be achieved by having teams of people with different responsibilities that work together to ensure the creation of accessible experiences.

When it comes to hiring and managing web development teams, it is needed for companies to consider accessibility in their hiring processes and management practices. Accessibility refers to the process of making digital products accessible and usable for people with disabilities. By considering accessibility in hiring and managing teams, companies can ensure that their digital products are more inclusive and usable for all users. This can also help to reduce the costs of compliance with accessibility regulations and improve the user experience for all customers.

Perhaps the most relevant question to the discussion of accessibility in the workplace is not “How do we find the perfect accessibility specialist?”, but instead “How do we build teams that make accessibility everyone’s responsibility?”.

I would love to hear your thoughts on this matter. Have you noticed that the role of accessibility roles within organizations has become more broad over the last few years?