3 ms·

Please don't implement WebMCP on your site. Support a11y / accessibility features instead. If browser or LLM providers care they will build to use existing spec

Please don't implement WebMCP on your site. Support a11y / accessibility features instead. If browser or LLM providers care they will build to use existing specs meant to health humans better interact with the web.

TechSquidTV 8mo ago
While you absolutely should, I would argue that MCP access would be the OPTIMAL level of accessibility.
- _heimdall 8mo ago
  Why? What does it add that accessibility features don't cover? And of there's a delta there, why have everyone build WebMCP into their sites rather than improve accessibility specs?
  - DrScientist 8mo ago
    Because, thinking bigger picture, having an AI assistant acting on your behalf might be more effective than slow navigation via accessibility features? I get the wider point that if accessibility features were good enough at describing the functionality and intent then you wouldn't need a separate WebMCP. So what does WebMCP do that accessibility doesn't? Seems to me, at cursory reading, it's around providing a direct js interface to the web site ( as oppose to DOM forms ). Kind of mixing an API and a human UI into one single page.
    - _heimdall 8mo ago
      Navigation shouldn't be slow when using accessibility features though. The browser already prices the accessibility tree with full context and semantics of what is on the page and what can be interacted with. I take the same issue when MCP servers are created for CLI tools. LLMs are very good at running Unix commands - make sure your tool has good `--help` docs and let the LLM figure it out just like a human would.
      - DrScientist 8mo ago
        I guess I was asking - assuming that WebMCP isn't totally misguided - which of course is an assumption - is there anything that current accessibility standards can learn from WebMCP - ie why did they feel the need to create it?
        _heimdall 8mo ago
        I'm not aware of anything WebMCP could add that wouldn't be more useful as an improvement to accessibility tooling instead. MCP is ultimately another solution to trying to make RPC(ish) situations more RESTful. I.e. they need self-documenting, discoverable APIs. That's exactly what you can get from both HTML and the accessibility tree, though. We don't need another implementation for it. My guess (conjecture here) is that all the skills, MCP, WebMCP, etc talk is a manifestation of all the model providers and VCs backing them trying desperately to have others find ways to make LLMs worth the cost.
        DrScientist 8mo ago
        Isn't Aria there to describe the structure of the page so that say visually impaired users gain the same information as any other user? ie the interpretation of what that page then does, and so the appropriate action to take is largely left to the human user post description - just as web you load a page and look at it - the human brain works out what to do based on those visual and textual clues. This leaves agents trying to work out page intent, allowed values for text fields - parsing returned pages for working out success or failure etc. I'm assuming that's why they want what is effectively an in page API - that massively improves machine accessibility and can piggy back on browser authentication systems so the agent can operate on the users behalf.
        _heimdall 8mo ago
        The website is the API though. HTML is one of the few RESTful systems people still use today, build semantics into the page and humans and LLMs can understand how to use it. A11y specs and APIs are just a way of presenting those semantics differently, often for those who can't see the page, whether visually impaired or in this case an LLM. At least in my view, we should expect anything claimed to be artificial intelligence to be able to interact with things much like a human would. I'm not going to build an MCP for a CLI tool, for example, I'll just make sure it has a useful man page or `--help` command.
- Natfan 8mo ago
  not from a legal perspective
charcircuit 8mo ago
Don't use accessibility features either. Just build for humans and let AI understanding take care of understanding all of the details.
- AlecSchueler 8mo ago
  Following accessibility best practice is what designing for humans looks like.
  - charcircuit 8mo ago
    The best practices are changing. Many accessibility features were built due to the computer not being understand correctly. For example how something that looks like a checkbox despite being just a div is would not get recognized properly. Now with AI, the AI understands what a checkbox is and can understand from the styling that there is a checkbox there.
    - johneth 8mo ago
      Or just use <input type="checkbox"> in the first place and save humans and machines a whole bunch of time.
      - charcircuit 8mo ago
        That's already possible today yet there are still people who don't which is why a more general solution for the screen reader is needed rather than requiring every site developer to do something special.
        _heimdall 8mo ago
        We shouldn't create general solutions for people building software poorly. We should help people build software better, in this by helping to promote the use of a11y specs. This is actually exactly where model providers could be doing some good. If they said a11y is the way for LLMs to interact with the web and helped push developers to docs, tutorials, etc the web would be better off. Google did effectively just that with HTTPS, they told everyone use it or lose SEO value rather than slapping some solution on Google's end to paper over poor security practices.
me551ah 8mo ago
Or have an a11y standard for MCPs, where they can't show UI elements and have to only respond with text so that Voice Readers could work out of the box. This would be a game changer, currenly Voice Readers do not work very well with websites and a11y is a clunky set of tags that you provide to elements and users need to move around elements with back/tab and try to make a mental model of what the website looks like. With MCP and Voice chat, it is like talking to a person.
- _heimdall 8mo ago
  Agreed that better browser support for accessibility tools is always welcome. I just don't think MCP is required at all there, the APIs are already well documented and built right into the browser.

TechSquidTV 8mo ago

While you absolutely should, I would argue that MCP access would be the OPTIMAL level of accessibility.

_heimdall 8mo ago
Why? What does it add that accessibility features don't cover? And of there's a delta there, why have everyone build WebMCP into their sites rather than improve accessibility specs?
- DrScientist 8mo ago
  Because, thinking bigger picture, having an AI assistant acting on your behalf might be more effective than slow navigation via accessibility features? I get the wider point that if accessibility features were good enough at describing the functionality and intent then you wouldn't need a separate WebMCP. So what does WebMCP do that accessibility doesn't? Seems to me, at cursory reading, it's around providing a direct js interface to the web site ( as oppose to DOM forms ). Kind of mixing an API and a human UI into one single page.
  - _heimdall 8mo ago
    Navigation shouldn't be slow when using accessibility features though. The browser already prices the accessibility tree with full context and semantics of what is on the page and what can be interacted with. I take the same issue when MCP servers are created for CLI tools. LLMs are very good at running Unix commands - make sure your tool has good `--help` docs and let the LLM figure it out just like a human would.
    - DrScientist 8mo ago
      I guess I was asking - assuming that WebMCP isn't totally misguided - which of course is an assumption - is there anything that current accessibility standards can learn from WebMCP - ie why did they feel the need to create it?
      - _heimdall 8mo ago
        I'm not aware of anything WebMCP could add that wouldn't be more useful as an improvement to accessibility tooling instead. MCP is ultimately another solution to trying to make RPC(ish) situations more RESTful. I.e. they need self-documenting, discoverable APIs. That's exactly what you can get from both HTML and the accessibility tree, though. We don't need another implementation for it. My guess (conjecture here) is that all the skills, MCP, WebMCP, etc talk is a manifestation of all the model providers and VCs backing them trying desperately to have others find ways to make LLMs worth the cost.
        DrScientist 8mo ago
        Isn't Aria there to describe the structure of the page so that say visually impaired users gain the same information as any other user? ie the interpretation of what that page then does, and so the appropriate action to take is largely left to the human user post description - just as web you load a page and look at it - the human brain works out what to do based on those visual and textual clues. This leaves agents trying to work out page intent, allowed values for text fields - parsing returned pages for working out success or failure etc. I'm assuming that's why they want what is effectively an in page API - that massively improves machine accessibility and can piggy back on browser authentication systems so the agent can operate on the users behalf.
        _heimdall 8mo ago
        The website is the API though. HTML is one of the few RESTful systems people still use today, build semantics into the page and humans and LLMs can understand how to use it. A11y specs and APIs are just a way of presenting those semantics differently, often for those who can't see the page, whether visually impaired or in this case an LLM. At least in my view, we should expect anything claimed to be artificial intelligence to be able to interact with things much like a human would. I'm not going to build an MCP for a CLI tool, for example, I'll just make sure it has a useful man page or `--help` command.
Natfan 8mo ago
not from a legal perspective

charcircuit 8mo ago

Don't use accessibility features either. Just build for humans and let AI understanding take care of understanding all of the details.

AlecSchueler 8mo ago
Following accessibility best practice is what designing for humans looks like.
- charcircuit 8mo ago
  The best practices are changing. Many accessibility features were built due to the computer not being understand correctly. For example how something that looks like a checkbox despite being just a div is would not get recognized properly. Now with AI, the AI understands what a checkbox is and can understand from the styling that there is a checkbox there.
  - johneth 8mo ago
    Or just use <input type="checkbox"> in the first place and save humans and machines a whole bunch of time.
    - charcircuit 8mo ago
      That's already possible today yet there are still people who don't which is why a more general solution for the screen reader is needed rather than requiring every site developer to do something special.
      - _heimdall 8mo ago
        We shouldn't create general solutions for people building software poorly. We should help people build software better, in this by helping to promote the use of a11y specs. This is actually exactly where model providers could be doing some good. If they said a11y is the way for LLMs to interact with the web and helped push developers to docs, tutorials, etc the web would be better off. Google did effectively just that with HTTPS, they told everyone use it or lose SEO value rather than slapping some solution on Google's end to paper over poor security practices.

me551ah 8mo ago

Or have an a11y standard for MCPs, where they can't show UI elements and have to only respond with text so that Voice Readers could work out of the box. This would be a game changer, currenly Voice Readers do not work very well with websites and a11y is a clunky set of tags that you provide to elements and users need to move around elements with back/tab and try to make a mental model of what the website looks like. With MCP and Voice chat, it is like talking to a person.

_heimdall 8mo ago
Agreed that better browser support for accessibility tools is always welcome. I just don't think MCP is required at all there, the APIs are already well documented and built right into the browser.