Accessibility

The target, in plain words

WCAG 2.2 AA is a published checklist. Roughly: text has to be readable against what's behind it, anything you can do with a finger you can also do with a keyboard, nothing important is carried by colour alone, the page has to still work at 200% zoom, controls have to be big enough to hit, and animation has to back off when your device asks it to.

No law forces a level here. One was picked and published anyway, so there's something specific to measure against and so the failures below have a name instead of being invisible.

Two things go past the minimum on purpose. The counting target is the whole screen above the two-tab bottom bar, against a 24 by 24 pixel minimum. The body text colour clears 12 to 1 in all 3 themes, against a 4.5 to 1 floor.

What's built today

Everything in this list was checked against the code before it was written down. Where something is only half done, it says so.

• The counting surface is a real button labelled "Count dhikr". It fills the screen above the bottom tab bar and it's the first thing the Tab key reaches. Switch Control, Voice Control and screen reader activation all synthesise a click rather than a touch, and the click path counts, so those routes have something to land on.
• Keyboard and Bluetooth pedal. Space, Enter, right arrow and Page Down count. Backspace, left arrow and Page Up take one back. Those are codes a page-turner pedal sends, so a pedal is a real input route here.
• Holding a key down doesn't run the count up. The page-level key handler ignores the operating system's auto-repeat, which otherwise turns a resting foot on a pedal into hundreds of counts.
• Touching a control with a finger or a mouse drops its focus. Without that, tapping Reset leaves it focused and the next Space re-fires Reset instead of counting, which wipes the count. Keyboard activation keeps focus, the way it should.
• The screen reader announcement is deliberately quiet. A polite live region speaks at every 33, when a target lands, when a step of the post-salah sequence advances, on undo and on reset. It says nothing on an ordinary tap, because 100 announcements in one session is unusable. The number and the "of 33" label are plain text on the page, so you can read the current count whenever you want it.
• Keyboard focus is visible everywhere. A 2 pixel accent outline sits 3 pixels clear of any control that takes focus.
• Contrast is computed and written into the stylesheet next to each colour. The smallest text colour, used for target labels, hints and settings sublabels, is 4.89 to 1 in light, 7.69 to 1 in dark and 5.25 to 1 in night, against a 4.5 to 1 requirement. It used to fail in 2 of those 3 themes. That was caught in review and fixed.
• Reduced motion is respected across the tap ripple, completion glow, count animation, ring sweep, bead strand and the breathing plus sign in the classic layout. When your device asks for less motion, those effects stop or shorten.
• Touch targets. The counting surface is the screen. The 4 controls in the top row and the 3 round buttons in the bottom bar are 56 by 56 pixels. The info button beside the transliteration and the post-salah start button are 44 tall. Two fall short: the style switcher buttons are 36 pixels tall, and "Done" in the info sheet is text height, roughly 20 pixels, under the 24 pixel floor. Nothing sits next to that one, so a miss is a harmless no-op.
• Both the settings and info sheets move focus inside when opened, keep Tab and Shift+Tab within the sheet, close on Escape or a tap outside, and return focus to the control that opened them.
• Pinch zoom stays on. Maximum scale is left unset on purpose in both root layouts, with a comment saying why, even though an accidental pinch mid-dhikr is never what anyone wanted.
• Arabic text carries its own language and direction markers, on the counter and inside the info sheet, so a screen reader switches voice instead of spelling it out in English. The page language and direction are set on the html element per locale.

Known gaps, still open

These come from the project's own interface review, which confirmed 32 defects across the whole app and ranked them.

What follows is the accessibility work still outstanding. It's written down and prioritised, not undiscovered. Until it's closed, AA is the target rather than a description of the site.

• The onboarding hint under the counter and the "+" inside the ring are drawn at reduced opacity. The colours they use pass on their own, and the transparency drops them back under the requirement, to somewhere between 2.3 and 3.4 to 1 for the hint depending on theme. That hint is the only sentence in the product that explains how it works.
• The counter screen doesn't reflow at 200% zoom on a phone. The top row can't shrink past the width of its 4 controls, so the page scrolls sideways and Settings can end up past the edge. Settings is where the large numbers toggle and the theme choice live, which is exactly what someone zoomed to 200% went looking for.

Closed, 10 August 2026

Three items from the list above, closed and moved here rather than deleted.

• A pedal keeps counting after a control has been used. The counting surface is a focus target now, and every control hands focus back to it once it has run, so the page handler is no longer sitting behind a focused button. The guard that lets Space and Enter activate a focused control stays, because removing it would break keyboard use altogether.
• Up arrow and down arrow count and undo. That was the one pedal pairing the handler did not recognise, so a pedal set to up and down did nothing at all.
• The tremor guard is a setting. It was fixed at 45 milliseconds, too fast for some tremors and too slow for fast counting. Four choices now: off, 45, 90 and 150 milliseconds. A hold-to-count alternative is still only an intention.
• On an installed iPhone app the top row clears the status bar and the Dynamic Island. This was fixed on 6 August and the gap list was never updated, so it sat here for 4 days after it stopped being true.

Closed, 6 August 2026

These were listed above as open and have since been fixed. They stay on the page because a list that only ever grows tells you nothing about whether anything gets done.

• Both dialogs now trap focus. Opening one moves focus to its first control, Tab and Shift+Tab wrap inside it, Escape closes it, and focus returns to the button that opened it. The info sheet previously had none of this.
• The same announcement twice in a row now speaks. Two live regions are written alternately, so reaching 33 a second time is a change to a different region rather than the same string reappearing in one.
• Where you are in the post-salah sequence is now text as well as dots, naming the step number and the phrase, and read by a screen reader.
• Controls hidden by focus mode are no longer reachable by keyboard. They were faded to invisible but still in the tab order, so Tab landed on things nobody could see.
• Reduced motion now reaches the ring sweep and the count animation. Both were set inline on the element, which outranked the stylesheet rule meant to switch them off.
• The light-theme ring fill was 2.36 to 1 against its own track, under the 3 to 1 minimum for a meaningful graphic. It now uses the darker accent.
• The top strip clears the status bar and the Dynamic Island on an installed iPhone app, which draws edge to edge.

What hasn't been tested

No screen reader test has been run against this site and no result has been recorded anywhere in the project. That's the largest hole in this statement, because everything in the built list above is a reading of the code rather than an observation of a real session.

Not tested, none of them:

• VoiceOver, on iOS and on macOS.
• TalkBack on Android.
• NVDA, JAWS and Narrator on Windows.
• iOS Switch Control and Android Switch Access. The full-screen button was built specifically so those two have an actionable target, and that assumption is unverified.
• Voice Control on iOS and Voice Access on Android.
• Braille displays.
• No session with anyone who depends on any of the above has been recorded either.

Reporting an accessibility problem

Email help@tasbih.info. Say what you were using, meaning the device, the browser and the assistive technology if there is one, and what happened. A screenshot or a short recording helps and isn't required.

One person reads that inbox, and it's the same person who writes the code, so nothing has to be relayed. Mufti Salim Qasmi builds and runs this site.

The commitment is the one already published on the corrections page: a reply within 7 days, even if it only says the report arrived. If 14 days pass and you've heard nothing, the email got lost, so please send it again.

If the report is a real defect it goes onto the open list on this page, whether or not it's fixed yet, and it stays there until it is. That's a commitment about how this page gets maintained. There's no ticketing system behind it and no mechanism in the software that enforces it.

If something on this page is wrong or out of date, that's worth an email too.

Counting without looking

The counter was built for people counting with their eyes lowered or closed, which is the normal posture for dhikr. The whole screen above the tab bar counts, so there's nothing to aim at, and a 12 millisecond vibration confirms every count when vibration is on, which is the default. Every 33 gives a distinct double tick, and a completed target gives a longer settling pattern.

You can tell where you are without looking, which is the thing a physical misbaha does. That helps blind users as well, and it was designed knowing it would.

It still falls short of screen reader support, which needs the announcements, the focus handling and the dialogs to all behave, and those are on the open list above.

One limit can't be solved from here. No version of iOS Safari is documented anywhere as supporting the vibration API, and this project treats iOS haptics as unverified rather than assuming either way. The app feature-tests at runtime, and both vibration settings switch themselves off with a note when the test fails, so on an iPhone the per-count confirmation is visual or audible only.

For a blind iPhone user that removes the one confirmation that costs no speech time, and there's no workaround this site can apply.