The way to make this work using Sapling (I think!) would be to transfer funds into a single-purpose (never previously used) Sapling address, and then submit a transaction with an expiry of block 570,000 (being the last block to be mined in) and selecting an anchor from block 569,999, which sends a zero-value output to the target recipient, and all funds out of the Sapling address (to a second single-purpose address). Then reveal the full viewing key (or possibly just the outgoing viewing key) for the first single-purpose address (not the second, for privacy). The block height window restriction (the transaction can only be mined in a single block) prevents people from creating multiple votes (because they can’t double-spend their funds within a single block), and using a fresh address (which should only be used for public-intended voting) means that only the transaction information for that usage is revealed. The downside to this is that if the transaction doesn’t get mined in the intended block, the vote doesn’t get counted.
Another alternative would be to create such a transaction, but not mine it, instead sending the transaction off-chain directly to some tally service (or posting it in the forum, or…). The fund-sending output would be sent like a change output (going back to the single-use address itself), eliminating the need for managing two such addresses. Using both an anchor and expiry of 570,000 would prevent the transaction from being mined, and would prove existence of the funds at that height. It would also reveal the nullifier corresponding to those funds, which would both ensure the funds were unspent at that height, and prevent a “double-spend” vote (because you’d see two votes with the same nullifier(s) being revealed). This also means that the nullifier could be detected later in chain when the funds are moved away from the address, but that’s not a terrible privacy leak if the tooling for doing this (wallets etc) move the funds out of the single-purpose address shortly after the vote. This could also be done after-the-fact without requiring the user to be online at the exact target block height (as long as the funds were moved into a “voting address” before the target block height), and in fact could be created after the funds have already been moved out of the voting address post-target height.