ಒಂದು AI ಸಾಧನವು ವಿಷಯವನ್ನು (content) ಸೃಷ್ಟಿಸುತ್ತಿರುವಾಗ, ಡೇಟಾಸೆಟ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡುತ್ತಿರುವಾಗ ಅಥವಾ ಸ್ವಾಯತ್ತ ಕಾರ್ಯವನ್ನು (autonomous task) ನಡೆಸುತ್ತಿರುವಾಗ, ಬಳಕೆದಾರರಿಗೆ ಹೊರಬರಲು ಸ್ಪಷ್ಟವಾದ ಮಾರ್ಗ ಬೇಕಾಗುತ್ತದೆ. ಅನೇಕ ಇಂಟರ್ಫೇಸ್‌ಗಳು ತುರ್ತು ನಿಲುಗಡೆಯನ್ನು (emergency stop) ಕೇವಲ ಒಂದು ನಂತರದ ಆಲೋಚನೆಯಾಗಿ ಪರಿಗಣಿಸುತ್ತವೆ. ಅವರು ಬಟನ್‌ನ ಲೇಬಲ್ ಅನ್ನು "Stop" ನಿಂದ "Stopped" ಗೆ ಬದಲಾಯಿಸಿ ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಬಣ್ಣವು ಬೂದು ಬಣ್ಣಕ್ಕೆ ಬದಲಾಗಬಹುದು. ಅನಿಮೇಷನ್ ಸುಗಮವಾಗಿ ಕಾಣಬಹುದು. ಆದರೂ ಕಾರ್ಯವು ಸರ್ವರ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಏನೂ ತಪ್ಪಾಗಿದೆ ಎಂಬುದು ಬಳಕೆದಾರರಿಗೆ ತಿಳಿಯುವುದಿಲ್ಲ. ಸ್ಕ್ರೀನ್ ರೀಡರ್ (screen reader) ಮೇಲೆ ಅವಲಂಬಿತರಾಗಿರುವವರಿಗೆ, ಈ ವೈಫಲ್ಯವು ಇನ್ನೂ ಹೆಚ್ಚು ಗಂಭೀರವಾದುದು. ಪ್ರಕ್ರಿಯೆಯು ಕೊನೆಗೊಂಡಿದೆ ಎಂಬ ಆಡಿಯೋ ದೃಢೀಕರಣವನ್ನು ಅವರು ಕೇಳುತ್ತಾರೆ, ಆದರೆ ಕೆಲಸವು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಮೌನವಾಗಿ ಮುಂದುವರಿಯುತ್ತಿರುತ್ತದೆ. ಇದು ಕೇವಲ ಸಣ್ಣ ದೋಷವಲ್ಲ (bug). ಇದು ನಂಬಿಕೆಯ ಕುಸಿತವಾಗಿದೆ.

ಸುಮ್ಮನೆ ಇರುವ ಸ್ಟಾಪ್ ಬಟನ್‌ನ ಸುಳ್ಳು

ಕೆಟ್ಟ ಸ್ಟಾಪ್ ಬಟನ್ ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತದೆ. ಕಾರ್ಯವು ಯಾವುದೋ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಅಥವಾ ರಿಮೋಟ್ ವರ್ಕರ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತಿದ್ದರೆ, ಅದು "Stopped" ಎಂಬ ಪದವನ್ನು ತೋರಿಸುತ್ತದೆ. ಸರ್ವರ್ ನಿಲುಗಡೆಯನ್ನು ದೃಢೀಕರಿಸುವ ಮೊದಲೇ ಫ್ರಂಟ್-ಎಂಡ್ (front-end) ಡೆವಲಪರ್‌ಗಳು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಅತೀ ಆಶಾವಾದದಿಂದ (optimistically) ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದರಿಂದ ಹೀಗಾಗುತ್ತದೆ. ಪ್ರೋಗ್ರೆಸ್ ಬಾರ್ ಚಲಿಸುತ್ತಿದ್ದರೆ ಅಥವಾ ಲಾಗ್ ಸ್ಕ್ರೋಲ್ ಆಗುತ್ತಿದ್ದರೆ ದೃಶ್ಯ ಬಳಕೆದಾರರು ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಬಹುದು, ಆದರೆ ಸ್ಕ್ರೀನ್-ರೀಡರ್ ಬಳಕೆದಾರರಿಗೆ ಅಂತಹ ಯಾವುದೇ ಪರ್ಯಾಯ ಮಾರ್ಗವಿಲ್ಲ. ಅವರು ಇಂಟರ್ಫೇಸ್ ಏನು ಘೋಷಿಸುತ್ತದೆಯೋ ಅದರ ಮೇಲೆ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿತರಾಗಿದ್ದಾರೆ. ಬಟನ್ ಪಠ್ಯವು ಅಕಾಲಿಕವಾಗಿ ಬದಲಾದರೆ ಮತ್ತು ಯಾವುದೇ ಆಡಿಯೋ ಫೀಡ್‌ಬ್ಯಾಕ್ ನಿಜವಾದ ಸ್ಥಿತಿಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸದಿದ್ದರೆ, ತುರ್ತು ಪರಿಸ್ಥಿತಿ ಮುಗಿದಿದೆ ಎಂದು ಬಳಕೆದಾರರು ನಂಬುತ್ತಾರೆ, ಆದರೆ ಅದು ನಿಜವಾಗಿರುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಸುಲಭ ಲಭ್ಯತೆ (Accessibility) ಎಂಬುದು ಕೇವಲ ಒಂದು ಫೀಚರ್ ವಿನತಿಯಲ್ಲ. ಅದು ಸುರಕ್ಷತೆಯ ಅವಶ್ಯಕತೆಯಾಗಿದೆ.

ಎರಡು ವಿಭಿನ್ನ ಸ್ಥಿತಿಗಳು

ನೈಜ ತುರ್ತು ನಿಯಂತ್ರಣವು ಎರಡು ವಿಭಿನ್ನ ಜವಾಬ್ದಾರಿಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ಮೊದಲನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಸಿಸ್ಟಮ್ ಅಧಿಕಾರವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ (revokes authority). ಇವೆರಡೂ ಒಂದೇ ಅಲ್ಲ. ಸ್ವೀಕಾರ ಎಂದರೆ ಫ್ರಂಟ್ ಎಂಡ್ ನಿಮ್ಮ ಮಾತನ್ನು ಕೇಳಿದೆ ಮತ್ತು ಸಂದೇಶವನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸಿದೆ ಎಂದರ್ಥ. ಹಿಂಪಡೆಯುವಿಕೆ ಎಂದರೆ ಬ್ಯಾಕ್ ಎಂಡ್ (back end) ವಾಸ್ತವವಾಗಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸಿದೆ ಎಂದರ್ಥ. ನೆಟ್‌ವರ್ಕ್ ವಿಳಂಬ (latency), ಜಾಬ್ ಕ್ಯೂಗಳು ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್‌ಗಳ ಅಸ್ತಿತ್ವದ ಕಾರಣದಿಂದಾಗಿ, ಆ ಎರಡು ಕ್ಷಣಗಳ ನಡುವಿನ ಅಂತರವು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಇರಬಹುದು. ಆ ಅವಧಿಯಲ್ಲಿ, ನೀವು ಯಾವ ಹಂತದಲ್ಲಿದ್ದೀರಿ ಎಂಬ ಬಗ್ಗೆ ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್ ಸತ್ಯವನ್ನು ಹೇಳಬೇಕು. ಎರಡೂ ಹಂತಗಳನ್ನು ಒಂದೇ ಕ್ಷಣದಲ್ಲಿ ಸಂಯೋಜಿಸುವುದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಮೂಲಸೌಕರ್ಯವನ್ನು (infrastructure) ಊಹಿಸಿದಂತೆ ಆಗುತ್ತದೆ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ಆ ಅತೀ ಆಶಾವಾದದ ಬೆಲೆಯನ್ನು ತೆರಬೇಕಾಗುತ್ತದೆ.

ನಾಲ್ಕು ಸ್ಥಿತಿಗಳನ್ನು ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಅಳವಡಿಸುವುದು

ಬಳಕೆದಾರರು ತಾವು ಎಲ್ಲಿ ನಿಂತಿದ್ದಾರೆ ಎಂಬುದು ಯಾವಾಗಲೂ ತಿಳಿಯುವಂತೆ ನಿಮ್ಮ UI ಅನ್ನು ನಾಲ್ಕು ಸ್ಪಷ್ಟ ಹಂತಗಳ ಸುತ್ತ ನಿರ್ಮಿಸಿ.

  • Running: ಸ್ಪಷ್ಟವಾಗಿ ಲೇಬಲ್ ಮಾಡಿದ "Stop task" ಬಟನ್ ತೋರಿಸಿ. ಅದನ್ನು ಯಾವಾಗಲೂ ದೃಶ್ಯಮಣೆಯಲ್ಲಿ ಇರಿಸಿ. ಟ್ಯಾಬ್‌ಗಳು ಅಥವಾ ಅಕಾರ್ಡಿಯನ್ ಪ್ಯಾನಲ್‌ಗಳ ಅಡಿಯಲ್ಲಿ ಅದನ್ನು ಮರೆಮಾಚಬೇಡಿ.
  • Requesting: ಬಳಕೆದಾರರು ಹೆಚ್ಚುವರಿ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸದಂತೆ ಬಟನ್ ಅನ್ನು ಡಿಸೇಬಲ್ (disable) ಮಾಡಿ. "Stop requested" ಸಂದೇಶವನ್ನು ಪ್ರದರ್ಶಿಸಿ. ಈ ಪ್ರಾಮಾಣಿಕತೆ ಮುಖ್ಯವಾಗಿದೆ. ಇದು ಬಳಕೆದಾರರ ಕಮಾಂಡ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಇನ್ನೂ ಪೂರ್ಣಗೊಂಡಿರುವುದನ್ನು ದೃಢೀಕರಿಸಿಲ್ಲ ಎಂದು ತಿಳಿಸುತ್ತದೆ.
  • Stopped: ಬಟನ್ ಅನ್ನು ಡಿಸೇಬಲ್ ಮಾಡಿ. ರಸೀದಿ ಐಡಿ (receipt ID) ತೋರಿಸಿ. ಇದು ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ ಮತ್ತು ಸ್ಟಾಪ್ ಅನ್ನು ದಾಖಲಿಸಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಬಳಕೆದಾರರಿಗೆ ಪುರಾವೆಯನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಕೇವಲ ಹೇಳಿಕೆಯನ್ನು ದಾಖಲೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
  • Failed: "Try stop again" ಬಟನ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ. ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯದ ಸಂದೇಶವನ್ನು ಪ್ರದರ್ಶಿಸಿ. ಬಳಕೆದಾರರನ್ನು ಮೌನದಲ್ಲಿ ಅನಿಶ್ಚಿತತೆಗೆ ಬಿಡಬೇಡಿ. ಸರ್ವರ್ ಟೈಮ್ ಔಟ್ ಆಗಿದ್ದರೆ ಅಥವಾ ದೋಷವನ್ನು ನೀಡಿದ್ದರೆ, ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ.

ಈ ಹಂತಗಳು ದೃಶ್ಯ ಮತ್ತು ಶ್ರವಣ ಎರಡೂ ಫೀಡ್‌ಬ್ಯಾಕ್ ಅನ್ನು ನೀಡಬೇಕು. ಹಂತವು ಬದಲಾದಾಗ, ಸ್ಕ್ರೀನ್ ರೀಡರ್‌ಗಳು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟ ಲೈವ್ ರೀಜನ್ (live region) ಮೂಲಕ ಹೊಸ ಲೇಬಲ್ ಮತ್ತು ಸ್ಥಿತಿಯನ್ನು ಘೋಷಿಸಬೇಕು. ಡಿಸೇಬಲ್ ಮಾಡಿದ ಬಟನ್ ಮತ್ತು ಪಠ್ಯದ ಘೋಷಣೆಯು ನಿಯಂತ್ರಣವು ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿದೆಯೇ ಎಂಬ ಗೊಂದಲವನ್ನು ತಡೆಯುತ್ತದೆ.

ಒತ್ತಡದ ಸಂದರ್ಭದಲ್ಲಿ ನಿಲ್ಲುವ ವಿನ್ಯಾಸದ ನಿಯಮಗಳು

ತುರ್ತು ನಿಯಂತ್ರಣಗಳು ಸಾಮಾನ್ಯ ಬಟನ್‌ಗಳಿಗಿಂತ ವಿಭಿನ್ನವಾದ ವಿನ್ಯಾಸದ ಹೊರೆ ಹೊತ್ತಿವೆ. ಬಳಕೆದಾರರು ಆತಂಕದಲ್ಲಿರಬಹುದು, ಅವಸರದಲ್ಲಿರಬಹುದು ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ಔಟ್‌ಪುಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿರಬಹುದು. ಅಂತಹ ಒತ್ತಡದ ಸಂದರ್ಭದಲ್ಲೂ ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್ ಬಳಕೆಗೆ ಸುಲಭವಾಗಿರಬೇಕು.

ಬಣ್ಣವನ್ನು ಮಾತ್ರ ಸಂಕೇತವಾಗಿ ಬಳಸಬೇಡಿ. ಬಟನ್ ಕೆಂಪಿನಿಂದ ಹಸಿರು ಬಣ್ಣಕ್ಕೆ ಬದಲಾಗುವುದು ಕೆಲವು ದೃಷ್ಟಿಬಲ್ಲ ಬಳಕೆದಾರರಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಕಲರ್ ಬ್ಲೈಂಡ್ (colorblind) ಮತ್ತು ಸ್ಕ್ರೀನ್-ರೀಡರ್ ಬಳಕೆದಾರರಿಗೆ ಪಠ್ಯ ಮತ್ತು ರಚನಾತ್ಮಕ ಬದಲಾವಣೆಗಳು ಬೇಕು. ಬಣ್ಣವನ್ನು ಸ್ಪಷ್ಟವಾದ ಲೇಬಲ್‌ಗಳೊಂದಿಗೆ, ಐಕಾನೋಗ್ರಫಿಯನ್ನು (iconography) ಪಠ್ಯದ ಪರ್ಯಾಯಗಳೊಂದಿಗೆ ಮತ್ತು ಸ್ಥಿತಿಯ ಘೋಷಣೆಗಳೊಂದಿಗೆ ಜೋಡಿಸಿ.

ನಿಯಂತ್ರಣಗಳನ್ನು ಹೋವರ್ (hover) ಮೆನುಗಳಲ್ಲಿ ಅಡಗಿಸಬೇಡಿ. ತುರ್ತು ಸಂದರ್ಭದಲ್ಲಿ ಯಾರೂ ಡ್ರಾಪ್‌ಡೌನ್ ಮೂಲಕ ಹುಡುಕುವಂತಿಲ್ಲ. ಸ್ಟಾಪ್ ಬಟನ್ ಪ್ರೈಮರಿ ವ್ಯೂಪೋರ್ಟ್‌ನಲ್ಲಿ (primary viewport) ಇರಬೇಕು ಮತ್ತು ನಿಖರವಾದ ಕರ್ಸರ್ ಚಲನೆಯಿಲ್ಲದೆಯೇ ಯಾವಾಗಲೂ ತಲುಪಲು ಸಾಧ್ಯವಾಗುವಂತಿರಬೇಕು.

ಬಟನ್‌ಗಳನ್ನು ಪಾಯಿಂಟರ್‌ನಿಂದ ಒತ್ತಲು ಸುಲಭವಾಗುವಂತೆ ಮಾಡಿ. ಒತ್ತಡವು ಸೂಕ್ಷ್ಮ ಚಲನಶೀಲತೆಯನ್ನು (fine motor control) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಹೆಚ್ಚಿನ ಪ್ಯಾಡಿಂಗ್ ಮತ್ತು ದೊಡ್ಡ ಹಿಟ್ ಟಾರ್ಗೆಟ್ ಬಳಸಿ. ಬಳಕೆದಾರರು ನಡುಗುತ್ತಿದ್ದರೆ ಅಥವಾ ಚಲಿಸುವ ರೈಲಿನಲ್ಲಿ ಟ್ರ್ಯಾಕ್‌ಪ್ಯಾಡ್ ಬಳಸುತ್ತಿದ್ದರೆ, ಅವರು ಕ್ಲಿಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಬೇಕು.

ಕೀಬೋರ್ಡ್ ಬಳಕೆದಾರರು ಬಟನ್ ಅನ್ನು ಶೀಘ್ರವಾಗಿ ತಲುಪುವಂತೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ತುರ್ತು ನಿಯಂತ್ರಣವನ್ನು ತಲುಪುವ ಮೊದಲು ಯಾರೂ ಮೂವತ್ತು ಫೋಕಸ್ ಮಾಡಬಹುದಾದ ಅಂಶಗಳ ಮೂಲಕ ಸೈಕಲ್ ಮಾಡಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲ. ಸ್ಟಾಪ್ ಕ್ರಿಯೆಯನ್ನು ತಕ್ಷಣವೇ ತಲುಪುವಂತೆ ಮಾಡಲು ಸ್ಕಿಪ್ ಲಿಂಕ್ (skip link) ಅಥವಾ ತಾರ್ಕಿಕ ಫೋಕಸ್ ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಅನ್ನು ಪರಿಗಣಿಸಿ.

ಅಚಾನಕ್ಕಾಗಿ ಬಳಸುವ ಕೀಬೋರ್ಡ್ ಶಾರ್ಟ್‌ಕಟ್‌ಗಳನ್ನು ತಪ್ಪಿಸಿ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸುವ ಗ್ಲೋಬಲ್ ಶಾರ್ಟ್‌ಕಟ್‌ಗಳು ತಪ್ಪಾಗಿ ಒತ್ತಲು ಕಷ್ಟವಾಗುವಂತಹ ಸಂಯೋಜನೆಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ಒಂದು ವೇಳೆ ಸಾಮಾನ್ಯ ಸೇವ್ (save) ಅಥವಾ ಪ್ರಿಂಟ್ (print) ಶಾರ್ಟ್‌ಕಟ್ ನಿಮ್ಮ ಸ್ಟಾಪ್ (stop) ಕಮಾಂಡ್‌ನೊಂದಿಗೆ ಒಂದೇ ಆಗಿದ್ದರೆ, ಯಾರಾದರೂ ಅದನ್ನು ಅಚಾನಕ್ಕಾಗಿ ಒತ್ತಬಹುದು ಮತ್ತು ಅವರ ಕೆಲಸವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು.

ತುರ್ತು ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಹು-ಹಂತದ ದೃಢೀಕರಣವನ್ನು ಬಳಸಬೇಡಿ. ದೃಢೀಕರಣ ಡೈಲಾಗ್ ಎಂಬುದು ಒಂದು ಅಡೆತಡೆಯೇ ಹೊರತು ಸುರಕ್ಷತಾ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲ. ಬಳಕೆದಾರರು "Are you sure?" ಎಂದು ಓದಿ ಮತ್ತೆ ಕ್ಲಿಕ್ ಮಾಡುವಷ್ಟರಲ್ಲಿ, ಅನಗತ್ಯ ಔಟ್‌ಪುಟ್ ಈಗಾಗಲೇ ಹೊರಹೋಗಿರಬಹುದು. ಒಂದು ನಿರ್ಣಾಯಕ ಕ್ರಮವು ಸಾಕಾಗಬೇಕು.

ರಸೀದಿಗಳು, ನೆಟ್‌ವರ್ಕ್ ನಷ್ಟ ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ಮಿತಿಗಳು

ರಸೀದಿ ಐಡಿ (receipt ID) ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆದರೆ ಅದು ಎಲ್ಲಾ ಕೆಳಮಟ್ಟದ ಪರಿಣಾಮಗಳು (downstream effects) ಹಿಂತಿರುಗಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸ್ಟಾಪ್ ಕಮಾಂಡ್ ಬರುವಷ್ಟರಲ್ಲಿ ನಿಮ್ಮ AI ಕಾರ್ಯವು ಬಾಹ್ಯ APIಗಳು, ಫೈಲ್ ಬರವಣಿಗೆಗಳು ಅಥವಾ ಮೆಸೇಜ್ ಕ್ಯೂಗಳನ್ನು (message queues) ಪ್ರಚೋದಿಸಿರಬಹುದು. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದು ಪ್ರತಿ ಚೈಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯು ತಕ್ಷಣವೇ ಸ್ಥಗಿತಗೊಂಡಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಸಂದೇಶಗಳು ಮತ್ತು ನಿಮ್ಮ ದಾಖಲೆಗಳಲ್ಲಿ (documentation) ಈ ಮಿತಿಯ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರಿ.

ನಿಮ್ಮ ಸರ್ವರ್ ರೂಮ್‌ನ ಹೊರಗಿರುವ ವೈಫಲ್ಯದ ವಿಧಾನಗಳಿಗೂ (failure modes) ನೀವು ವಿನ್ಯಾಸಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ. ಸ್ಟಾಪ್ ಕ್ಲಿಕ್ ಮಾಡಿದ ತಕ್ಷಣ ಬಳಕೆದಾರರು ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಕಳೆದುಕೊಂಡರೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪ್ರತಿಕ್ರಿಯೆಯು ನೂರು ಮಿಲಿಸೆಕೆನ್‌ಗಳ ಬದಲಿಗೆ ಹತ್ತು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರೀಕ್ಷಿಸಿ. ವಿನಂತಿಯು (request) ಸ್ಥಗಿತಗೊಂಡರೆ, ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್ ಎಂದಿಗೂ "Requesting" ಸ್ಥಿತಿಯಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುವ ಬದಲು ಫೇಲ್ಡ್ (failed) ಸ್ಥಿತಿಗೆ ತಲುಪಬೇಕು. ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಿದೆ ಎಂದು ತಿಳಿಯುವ ಹಕ್ಕು ಬಳಕೆದಾರರಿಗಿದೆ.

ಪ್ರಾಮುಖ್ಯತೆ ನೀಡುವ ರೀತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ

ಪರಿಶೀಲನೆಯು ಕೇವಲ ನಂತರದ ಕೆಲಸವಾಗಬಾರದು. ವಿಕಲಚೇತನ ಬಳಕೆದಾರರು ಪ್ರತಿದಿನ ಎದುರಿಸುವ ನೈಜ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ನಿಮ್ಮ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಕೀಬೋರ್ಡ್-ಮಾತ್ರದ ನ್ಯಾವಿಗೇಷನ್. ನಿಮ್ಮ ಮೌಸ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ. ಪ್ರತಿಯೊಂದು ಸ್ಥಿತಿಯ ಮೂಲಕ ಟ್ಯಾಬ್ (Tab) ಬಳಸಿ ಹೋಗಿ. ಫೋಕಸ್ (focus) ಸಿಲುಕಿಕೊಳ್ಳದಂತೆ ಅಥವಾ ಅದೃಶ್ಯ ಟ್ಯಾಬ್ ಸ್ಟಾಪ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸದಂತೆ, ವರ್ಕ್‌ಫ್ಲೋನಲ್ಲಿ ಎಲ್ಲಿಂದಲಾದರೂ ನೀವು ಸ್ಟಾಪ್ ಬಟನ್ ಅನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

200% ಬ್ರೌಸರ್ ಜೂಮ್. ಪುಟವನ್ನು ದೊಡ್ಡದಾಗಿ ಮಾಡಿ (magnify). ಸ್ಟಾಪ್ ಬಟನ್ ಸರಿಯಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆಯೇ ಅಥವಾ ಮಾಯವಾಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕಡಿಮೆ ದೃಷ್ಟಿ ಹೊಂದಿರುವ ಬಳಕೆದಾರರು ಜೂಮ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತಾರೆ ಮತ್ತು ಲೇಔಟ್ ಕುಸಿತವು (layout collapse) ಪ್ರಮುಖ ನಿಯಂತ್ರಣಗಳನ್ನು ಮರೆಮಾಚಬಹುದು.

ಕಡಿಮೆ ಚಲನೆಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳು (Reduced motion settings). ನಿಮ್ಮ "Requesting" ಸ್ಥಿತಿಯು ಪಲ್ಸಿಂಗ್ ಅನಿಮೇಷನ್ ಅಥವಾ ಸ್ಪಿನ್ನಿಂಗ್ ಲೋಡರ್ ಅನ್ನು ಬಳಸಬಹುದು. prefers-reduced-motion ಅನ್ನು ಗೌರವಿಸಿ. ಅನಿಮೇಷನ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬಳಕೆದಾರರಿಗೆ ಸ್ಪಷ್ಟವಾದ ಸ್ಥಿತಿಯ ಪ್ರತಿಕ್ರಿಯೆ ಸಿಗುವಂತೆ ಮಾಡಲು, ಯಾವುದೇ ಚಲನೆಯ ಜೊತೆಗೆ ಸ್ಥಿರವಾದ ದೃಶ್ಯ ಸೂಚಕಗಳನ್ನು (static visual indicators) ಒದಗಿಸಿ.

ಸ್ಕ್ರೀನ್ ರೀಡರ್ ಘೋಷಣಾ ಕ್ರಮ. ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರಸಾರ ಮಾಡಲು ಲೈವ್ ರೀಜನ್ (live region) ಬಳಸಿ, ಆದರೆ ಕ್ರಮವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರೀಕ್ಷಿಸಿ. ಘೋಷಣೆಯ ಕ್ರಮವು ಘಟನೆಗಳ ತಾರ್ಕಿಕ ಪ್ರಗತಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಸ್ಕ್ರೀನ್ ರೀಡರ್ "Stop requested" ಎಂದು ಹೇಳುವ ಮೊದಲೇ ಬಟನ್ ನಿಷ್ಕ್ರಿಯಗೊಂಡರೆ, ಆ ಕ್ರಮವು ಗೊಂದಲವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆಯೇ ಎಂದು ಪರೀಕ್ಷಿಸಿ. ಸಹಾಯಕ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿನ (assistive technology) ಸಣ್ಣ ಸಮಯದ ದೋಷಗಳು ಸಂದೇಶವನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸಬಹುದು, ಆದ್ದರಿಂದ ಮಾರ್ಕಪ್ (markup) ಸಾಕಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು ನೈಜ ಸ್ಕ್ರೀನ್ ರೀಡರ್ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ.

ನಿಜವಾದ ಸಾರಾಂಶ

ಸುಲಭವಾಗಿ ಲಭ್ಯವಾಗುವ (accessible) ತುರ್ತು ನಿಲುಗಡೆ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಸತ್ಯವನ್ನು ಹೇಳುವಷ್ಟು ಅವರನ್ನು ಗೌರವಿಸುವುದು ಎಂದರ್ಥ. ಇಂಟರ್ಫೇಸ್ ಸರಳವಾಗಿರಬೇಕು, ಮುನ್ಸೂಚನೆ ನೀಡುವ ರೀತಿಯಲ್ಲಿ ಚಲಿಸಬೇಕು ಮತ್ತು ವಿನಂತಿಯು (request) ಫಲಿತಾಂಶದ (result)ಂತೆಯೇ ಎಂದು ಎಂದಿಗೂ ನಟಿಸಬಾರದು. ಒತ್ತಡ ಹೆಚ್ಚಿದ್ದಾಗ ಮತ್ತು ಡೇಟಾ ಅಪಾಯದಲ್ಲಿದ್ದಾಗ, ಸ್ಪಷ್ಟತೆಯು ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಉಳಿಸುತ್ತದೆ. ಅದು ನಂಬಿಕೆಯನ್ನು ಉಳಿಸುತ್ತದೆ. ಪ್ರಾಮಾಣಿಕವಾದ ಸ್ಟಾಪ್ ಬಟನ್ ಕೇವಲ ಕಾರ್ಯವನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ; ಅದು ನಿಮ್ಮ ಉತ್ಪನ್ನವು ಬಳಸಲು ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂಬುದನ್ನು ಮೊದಲೇ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.