Range Optimizer in Mysql: What is an Index dive during Query Optimization?
To "dive" is to drill down the BTree from the 'root' down to the leaf node for a particular key.

Let's say you have a non-unique INDEX(x).  Further, let's say that there are 100 rows with x=123.  WHERE x = 123, the two dives would be to "find the first index entry for x=123" and to find the "last" such row.

His first use of "accurate" (in the article) was to say that the dives are more accurate than using statistics that may be stale.

I suspect his use of "accurate" is an exaggeration in the other uses.  I say this because I cannot believe that counting the rows between the first and last dive is no more than an estimation.  To get the exact number would require fetching each block -- this is too costly.

Note the 100 rows might be in the same block, or might (if the rows are wide) be spread across multiple blocks.  For the purposes of EXPLAIN and query planning, an estimate is considered "good enough".  The exact ("accurate") number can be quickly counted if the start and end are in the same block, but, if spread across multiple blocks, I think then it would only estimate the row counts for the intermediate blocks.

The "dives", even if they involve a disk-read, are usually not wasted.  This is because you will (presumably) then proceed to perform the query and need those block(s) anyway.

Side note:  Since Jørgen Løland wrote that article, the Optimizer has employed a "cost basis" algorithm.  However, the "dives" are still important in it.