Comment by jeroenhd
19 hours ago
> Yeah a screenreader functions as a sequential medium, so what happens with registry of all share targets with screenreader, in fact what happens when screenreader comes to site, screenreader now will tell you that you have shares first? This is up to the browser how they tell the user that there are shares and ask for their input? So it will work differently between browsers?
Both Android and iOS have sharing mechanisms that work just fine with screen readers. They show the most common/likey/favourited options first, with an option to expand to other apps/share targets. My phone has dozens of options, but I rarely need to scroll beyond the first line to find the share target I'm looking for.
The share dialog is an OS/browser control, not something the web page needs to render, so it's as accessible as the browser decides it should be. Many Linux distros lack such a control, but on Android/iOS/Windows/presumably macOS, this is a solved problem.
the problem for me at any rate, reading the spec, is trying to think out exactly how this will be affected by the ability of the site to add multiple share targets
as quoted >The user agent MAY automatically register all web share targets as the user visits the site, but it is RECOMMENDED that more discretion is applied, to avoid overwhelming the user with the choice of a large number of targets.
The spec evidently feels it won't make any difference at all, but I'm not sure, and it's harder for me to reason about this than the simple rel share url thing.