Comment 1 by jteh on 2010-06-30 22:24
Changes:
Milestone changed from 2010.2 to None

CC @LeonarddeR, @ruifontes.

I realise other screen readers have this functionality, but I'd argue we shouldn't implement this as requested for several reasons:

1. Performance: This could be quite slow.
   • For virtual buffers, we still need to walk the entire virtual buffer tree to get this information. Alternatively, we could maintain counts for element types of interest as we build and update the buffer, but that introduces a fair bit of complexity.
   • We're moving away from virtual buffers. We don't use them for neither Edge nor Kindle and it's probable we will move away from them for Firefox and Chrome as well at some point. Once that happens, this will be even slower.
2. Usefulness: Why is it useful to know the exact number of links, headings, etc.? I can understand someone wanting to know that certain types of things are present, but why the number of them? If it's about knowing what types of things are present, why not just "Document has headings, links and landmarks"?
3. Accuracy: The idea of when a page finishes "loading" is becoming less and less relevant. We start reading the document when there's something useful to read. We haven't waited for the DOM "load" event for many years now because on the modern web, this might take a very long time to arrive (or may never arrive at all). Also, some pages load content dynamically. If we're giving the user exact counts, the user may trust those counts to be accurate. And if they can't, why are we counting at all? See point 2.
4. Equivalent experience: There is no equivalent experience for a sighted user. Sure, if there's something a sighted user can do and making that accessible just doesn't "fit" for a screen reader user, we might implement an alternative method to achieve it; e.g. quick navigation is an alternative to a sighted person "skimming" the page with their eyes. However, counting links, headings, etc. is just not something anyone would waste their time doing. Sure, they might identify the kinds of things on a page, but that has nothing to do with counting.
5. Verbosity: This increases the amount of stuff a user has to wait through before they can get on with reading the page. I guess making this optional mitigates this, but I'd want it disabled by default in that case, which raises the question of whether anyone would actually enable it.

As always, please provide real world use cases to justify the need for this. From there, we can figure out the best user experience.

Generally I use stammetric counting of objects to quickly know if the page I just opened is very extense, and it will take me a long time to get to know the content of the page.

@elliott94 @jcsteh raises some fair points and makes some powerful arguments against this functionality. As the original author of this ticket, do you have any remarks or responses?

This was initially logged at a time when I'd just switched from JAWS to NVDA. I'm happy for this to be closed if that's the general opinion.

Has anyone looked at this issue lately? I had a request from a user for it today.

To me it looks like the feature as described will not be implemented, reasons for this are well explained in previous comments. There is potentially a remaining use case for providing some kind of skimmed overview of a page. Though the specific goals have not been well defined. This issue currently reads like an implementation in search of justification. I'd prefer to close this issue.

One suggestion from my side at least, could this not be acomplished in the elements list? At least for the elements that can be chosen there? The radio buttons could contain also the number of the elements (i.e. link 320 radio button, headings, 20 radio button etc.). However, I think even this would have a big impact on performance. I wonder how Jaws does this?