Accessibility, Security, Privacy, and Ethical Design

Introduction

Frontend applications increasingly mediate access to education, employment, healthcare, finance, government, and social participation. A React or Vue interface is therefore not merely a visual layer. It is a socio-technical system that can include or exclude users, expose or protect personal information, reinforce or challenge social inequalities, and create or reduce security risk.

Accessibility, security, privacy, and ethics are related but distinct design obligations. Accessibility concerns whether people with diverse abilities can perceive, operate, understand, and interact with a system. Security concerns protection against unauthorized access, manipulation, disruption, and abuse. Privacy concerns appropriate control over the collection, use, disclosure, and retention of personal data. Ethical design concerns whether the system and its organizational purposes are fair, explainable, accountable, and respectful of human autonomy.

React and Vue provide useful abstractions—components, state management, routing, server communication, and reusable design systems—but they do not automatically produce responsible software. A component can be reusable and still be inaccessible; a client-side route guard can improve user experience while providing no real authorization; a consent dialog can comply visually while manipulating users into disclosure.

This chapter develops an integrated approach to responsible frontend engineering. It combines standards-oriented accessibility, threat-informed security, privacy-by-design, and ethical analysis with practical React and Vue techniques.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the conceptual relationship and differences among accessibility, security, privacy, and ethical design.
2. Apply WCAG principles and semantic HTML to React and Vue interfaces.
3. Identify major frontend threats, including XSS, CSRF, clickjacking, supply-chain compromise, and insecure authorization assumptions.
4. Design privacy-preserving data flows, consent mechanisms, and storage strategies.
5. Evaluate interfaces using ethical frameworks such as autonomy, beneficence, non-maleficence, justice, and accountability.
6. Construct a cross-functional quality assurance and governance process.
7. Analyze a realistic case involving conflicting accessibility, security, privacy, and business requirements.

1. A Unified Responsibility Model

A useful starting point is to distinguish four questions:

These dimensions interact. A CAPTCHA may reduce automated abuse but exclude users with cognitive or visual disabilities. Aggressive fraud detection may protect an account while incorrectly blocking users from a particular region. A session timeout may improve security but cause hardship for users who need more time. The correct response is not to rank one concern permanently above the others, but to identify risks, affected stakeholders, legal duties, and proportionate mitigations.

Responsible design is also a lifecycle activity. Requirements, architecture, implementation, testing, deployment, monitoring, incident response, and retirement all influence outcomes. Accessibility defects may originate in a design system; privacy violations may originate in analytics configuration; security vulnerabilities may arise through a third-party package; ethical harms may become visible only after deployment.

2. Accessibility as Inclusive Interaction Design

2.1 The accessibility model

The Web Content Accessibility Guidelines (WCAG) organize accessibility around four principles, commonly summarized as POUR:

• Perceivable: Information and controls can be perceived, including through text alternatives, captions, contrast, and adaptable presentation.
• Operable: Users can operate controls through available input methods, including keyboard navigation and assistive technology.
• Understandable: Content and interaction behavior are predictable and comprehensible.
• Robust: Content works with current and future browsers, platforms, and assistive technologies.

WCAG conformance levels—A, AA, and AAA—represent increasing success-criterion coverage. In professional projects, WCAG 2.2 Level AA is a common target, but conformance is not identical to usability. A technically conforming interface can still be confusing, slow, culturally inappropriate, or unusable with a particular assistive technology. Automated tools detect only a subset of accessibility defects; human testing remains essential.

Accessibility should be understood through the social model of disability as well as the medical model. The medical model locates disability primarily in an individual condition. The social model emphasizes barriers created by environments, institutions, and technologies. In frontend engineering, this implies that a missing label, poor focus management, or inaccessible authentication process is a design failure rather than merely a user limitation.

2.2 Semantic structure and component design

Semantic HTML communicates meaning to browsers and assistive technologies. Prefer <button> for an action, <a> for navigation, <label> for a form control, headings in logical order, lists for lists, and table headers for tabular relationships. A clickable <div> usually requires recreating keyboard behavior, focus behavior, and semantics that the native button already supplies.

React example:

function SaveButton({ saving, onSave }) {
  return (
    <button type="button" onClick={onSave} disabled={saving}>
      {saving ? 'Saving…' : 'Save changes'}
    </button>
  );
}

Vue example:

<script setup>
defineProps({ saving: Boolean })
defineEmits(['save'])
</script>

<template>
  <button type="button" :disabled="saving" @click="$emit('save')">
    {{ saving ? 'Saving…' : 'Save changes' }}
  </button>
</template>

The text communicates state, while the native button provides keyboard and assistive-technology behavior. If an icon is used, its purpose must be communicated through an accessible name or an adjacent visible label. Decorative images should have empty alternative text (alt="") so that screen readers do not announce irrelevant content.

2.3 Focus, dynamic content, and single-page applications

Single-page applications create accessibility challenges because navigation may occur without a full page load. When route content changes, the document title should be updated and focus should move predictably—often to the main heading or a suitable page container. Focus should never be moved arbitrarily, because unexpected focus movement is disorienting.

Modal dialogs require a focus strategy: move focus into the dialog, keep keyboard focus within it while open, provide an accessible name, support Escape where appropriate, and return focus to the invoking control when closed. A dialog must not merely be visually displayed while background controls remain keyboard-accessible.

Live regions can announce asynchronous updates such as “Profile saved.” They should be used sparingly. Excessive announcements create cognitive overload, and an assertive announcement may interrupt important speech. Loading indicators should communicate status without relying exclusively on animation or color.

2.4 Forms and error prevention

Accessible forms require explicit labels, useful instructions, programmatically associated errors, and preservation of user-entered data when validation fails. Error messages should identify the field and explain how to correct it. Do not rely only on red borders, because color alone is insufficient for many users.

For example, an input may use an accessible description and error association:

<label htmlFor="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-help email-error"
  aria-invalid={Boolean(error)}
/>
<p id="email-help">Use an address you can access.</p>
{error && <p id="email-error" role="alert">Enter a valid email address.</p>}

Client-side validation improves immediacy but is not a security boundary. The server must validate the same business rules, because requests can be generated without the interface.

2.5 Testing accessibility

A mature testing program combines:

1. Static analysis: ESLint accessibility rules and component checks.
2. Automated evaluation: Tools such as axe-based testing for common detectable violations.
3. Keyboard testing: Logical tab order, visible focus, skip links, and no keyboard traps.
4. Screen-reader testing: At least one screen reader and browser combination relevant to the target population.
5. Zoom, reflow, and contrast testing: Including small screens and enlarged text.
6. User research: Participants with disabilities performing realistic tasks.

Accessibility testing should be integrated into pull requests and design reviews rather than postponed until release.

3. Frontend Security: Threats and Controls

3.1 Security boundaries

The browser is an untrusted environment. Users can modify JavaScript, inspect network requests, alter local storage, disable controls, and call APIs directly. Consequently:

• A hidden button is not authorization.
• A client-side route guard is not authorization.
• A value in local storage is not trustworthy evidence of identity or privilege.
• Client-side validation is not sufficient input validation.

The server or a trusted backend must authenticate the user, authorize each protected operation, validate input, enforce business rules, and record security-relevant events. The frontend remains important because it can prevent accidental misuse, reduce exposure, and present security states clearly, but it cannot establish trust by itself.

3.2 Cross-site scripting (XSS)

XSS occurs when attacker-controlled content is interpreted as executable script in a user’s browser. React escapes interpolated text by default, and Vue escapes ordinary template interpolation by default. Risk increases when developers use mechanisms such as React’s dangerouslySetInnerHTML, Vue’s v-html, unsafe URL construction, or third-party HTML rendering.

A safer policy is to avoid rendering raw HTML. If rich text is required, sanitize it with a well-maintained, appropriately configured sanitizer, enforce a restrictive Content Security Policy (CSP), and treat sanitized output as context-specific. Sanitization is not a substitute for output encoding in every context.

Never construct HTML or JavaScript from untrusted data. URLs also require validation: an attacker may attempt schemes such as javascript: where a component expects an ordinary hyperlink.

3.3 Authentication, sessions, and authorization

Authentication establishes identity; authorization determines permitted actions. Use established identity protocols and backend session mechanisms rather than inventing cryptography in frontend code. Session cookies should generally be configured with Secure, HttpOnly, and an appropriate SameSite attribute. HttpOnly prevents JavaScript from reading the cookie, reducing certain token-theft consequences, although it does not prevent all attacks.

For sensitive operations, require reauthentication or step-up authentication where appropriate. Protect password reset, payment, account recovery, and privilege changes with server-side controls, rate limiting, audit records, and safe error messages.

Authorization must be checked on every relevant server request. A role rendered in a React context or Vue store is a presentation aid, not a proof of permission.

3.4 CSRF, clickjacking, and supply-chain threats

Cross-site request forgery (CSRF) abuses an authenticated browser session to induce an unwanted state-changing request. Defenses include appropriate SameSite cookies, CSRF tokens, origin verification, and avoiding state changes through GET requests. The exact defense depends on the session architecture.

Clickjacking overlays or frames a legitimate interface to trick users into clicking. Frame-ancestors in CSP and suitable framing headers provide important defenses.

Frontend applications depend on package registries, build tools, analytics libraries, UI components, and external scripts. A compromised dependency can exfiltrate data or modify transactions. Controls include dependency pinning and review, lockfiles, vulnerability scanning, software bills of materials, minimized third-party code, integrity controls where applicable, and rapid patch processes. A package’s popularity is not proof of safety.

3.5 Security usability

Security controls that users cannot understand may generate workarounds. Error messages should avoid revealing sensitive account information while still supporting legitimate recovery. Password interfaces should permit password managers and paste operations. Multi-factor authentication should offer accessible recovery and alternative factors without weakening the security model. Security and accessibility are jointly optimized through threat modeling and user testing.

4. Privacy and Data Governance

4.1 Privacy principles

Privacy is more than secrecy. It includes contextual integrity, user agency, appropriate purpose, proportionality, and control over personal information. Common privacy principles include:

• Purpose limitation: Collect and use data for specified purposes.
• Data minimization: Collect only what is necessary.
• Accuracy: Permit correction of materially inaccurate data.
• Storage limitation: Retain data no longer than justified.
• Security: Protect data against unauthorized access and loss.
• Transparency: Explain data practices in understandable language.
• Accountability: Demonstrate compliance and respond to complaints or incidents.

Legal requirements differ across jurisdictions. Depending on the context, organizations may need to consider data-protection laws, sectoral rules, children’s privacy requirements, accessibility law, consumer-protection law, and contractual obligations. Legal compliance is a baseline, not a complete ethical analysis.

4.2 Data mapping and frontend architecture

Before implementing a feature, map the data lifecycle:

1. What data is collected?
2. From whom and through which control?
3. Where is it stored and transmitted?
4. Which services and people can access it?
5. For what purpose is it used?
6. How long is it retained?
7. How can it be corrected, exported, or deleted?
8. What happens if the user refuses consent?

Avoid putting sensitive data in URLs, browser history, logs, analytics events, or local storage without a strong justification. Local storage is readable by JavaScript and is vulnerable to exfiltration through XSS. Do not store authentication secrets there merely because it is convenient.

Analytics events should be designed as data products. An event such as checkout_completed may be useful without including a full name, email address, exact address, or payment details. Identifiers should be pseudonymous where possible, and pseudonymization does not make data anonymous if re-identification remains possible.

4.3 Consent and privacy interfaces

Valid consent is generally expected to be informed, specific, freely given, and withdrawable where consent is the legal basis. A consent banner should not obscure the service, preselect optional tracking, or make acceptance substantially easier than refusal. Necessary processing should not be misrepresented as optional marketing, and withdrawing consent should be comparably easy.

Privacy notices should explain purposes, categories of data, retention, sharing, rights, and contact mechanisms in plain language. Layered notices can provide a concise explanation with access to fuller details. Localization and accessible presentation are part of meaningful transparency.

Privacy-enhancing techniques include local processing, aggregation, coarse location, short retention periods, access controls, encryption in transit and at rest, and differential privacy where statistical release requires formal protection. Differential privacy is a technical research area and should not be claimed merely because data is aggregated; its guarantees depend on a defined mechanism and privacy budget.

5. Ethical Design and Critical Evaluation

5.1 Ethical principles

An ethical review can ask:

• Autonomy: Does the interface support informed, uncoerced choice?
• Beneficence: Does it create meaningful benefits?
• Non-maleficence: What foreseeable harms might result?
• Justice: Are benefits and burdens distributed fairly?
• Explicability: Can decisions and data practices be explained?
• Accountability: Who can investigate, correct, and remedy failures?

These principles may conflict. Personalization may improve convenience but require extensive surveillance. Fraud prevention may reduce losses but create disparate false positives. A responsible team documents trade-offs rather than presenting a technical choice as value-neutral.

5.2 Dark patterns and persuasive systems

Dark patterns manipulate users through interface choices such as disguised advertisements, confirmshaming, obstructive cancellation, false urgency, hidden costs, and confusing consent controls. Persuasive design is not automatically unethical; reminders and defaults can support beneficial behavior. The critical questions are whether the choice is understandable, reversible, proportionate, and aligned with the user’s interests rather than solely with organizational extraction.

A practical review examines the complete journey, not only individual screens. A neutral-looking button may become coercive when refusal causes repeated prompts, loss of functionality unrelated to tracking, or social pressure.

5.3 Algorithmic and AI-assisted interfaces

Frontend systems increasingly display recommendations, risk scores, generated text, and automated decisions. Designers must communicate when automation is involved, distinguish generated content from verified facts, provide meaningful correction or appeal routes, and avoid implying certainty unsupported by evidence. Personalization can create filter bubbles or discriminatory treatment. Accessibility also matters: generated captions, alternative text, and summaries require quality checks and must not erase user control.

AI coding assistants introduce security and privacy risks. Developers should not paste secrets, personal records, proprietary source code, or regulated data into tools without organizational authorization. Generated code requires human review for dependency risk, insecure patterns, licensing issues, accessibility, and misleading assumptions.

6. An Integrated Engineering Process

A professional process embeds responsibility into delivery:

Requirements and discovery

Identify users with varied abilities, data subjects, administrators, maintainers, and people indirectly affected. Record legal and policy constraints, abuse cases, accessibility needs, and unacceptable outcomes.

Design

Use semantic design-system components. Create data-flow diagrams, threat models, privacy impact assessments where appropriate, and ethical impact questions. Define measurable acceptance criteria—for example, keyboard completion of a critical journey, no sensitive information in analytics, and server enforcement of authorization.

Implementation

Prefer native semantics, safe framework defaults, strict typing where useful, secure headers, dependency governance, and centralized error handling. Separate presentation state from security decisions. Keep secrets out of frontend bundles; anything shipped to the browser should be treated as public.

Verification

Combine unit, integration, end-to-end, accessibility, security, privacy, and usability testing. Test failure states, expired sessions, denied permissions, slow networks, keyboard-only operation, screen readers, localization, and assistive technology. Review third-party scripts and generated code.

Release and operation

Use staged deployment, monitoring, incident response, vulnerability disclosure, rollback capability, and change records. Monitor accessibility regressions and privacy configuration drift, not only uptime. Establish a process for users to report barriers, security vulnerabilities, and data concerns.

7. Applied Case: A University Financial-Aid Portal

The following is an illustrative case.

Background

A university builds a React portal through which students submit financial-aid applications. The portal collects income information, disability-related documentation, identity data, and bank details. The product team proposes aggressive analytics, a third-party identity widget, automated document classification, and a ten-minute inactivity timeout.

Problem

Pilot testing reveals four risks. Screen-reader users cannot identify several form errors. The identity widget traps keyboard focus. The analytics vendor receives page URLs containing student identifiers. Finally, students who need more than ten minutes to assemble documents are repeatedly logged out. The security team also discovers that the frontend hides administrative actions but the API does not consistently verify permissions.

Analysis

The accessibility issues violate basic perceivability and operability expectations. The URL design creates unnecessary disclosure through browser history, referrer transmission, logs, and analytics. The timeout may reduce session exposure but imposes disproportionate burdens on users with motor, cognitive, or connectivity-related constraints. The authorization defect is a high-severity security problem because a malicious user could bypass the interface and call the API directly.

Ethically, the portal concerns a high-impact domain: denial or delay may affect housing, education, and food security. Automated document classification should assist staff rather than silently determine eligibility. Students need an explanation and appeal path when classification is uncertain.

Approach and solution

The team takes the following actions:

1. Replaces custom clickable containers with semantic controls and adds field-level error associations.
2. Requires the identity vendor to meet keyboard and screen-reader requirements, with an accessible fallback.
3. Removes identifiers from URLs and configures analytics to receive only necessary, pseudonymous events.
4. Replaces the fixed timeout with an inactivity warning, secure token rotation, explicit sign-out, and a user-controlled save-and-return workflow. High-risk actions still require reauthentication.
5. Enforces authorization on every API endpoint and tests forbidden requests independently of the UI.
6. Limits document classification to a recommendation, records confidence and provenance, and provides human review and appeal.
7. Conducts keyboard, screen-reader, privacy, threat-model, and student-participant testing before release.

Outcome

The revised portal allows completion of the primary journey without a mouse, reduces unnecessary data transmission, and prevents unauthorized administrative operations. Students can save progress and return without weakening protection for sensitive actions. Staff receive classification assistance but remain accountable for decisions.

Learning points

The case demonstrates that accessibility, security, privacy, and ethics cannot be solved by isolated specialists at the end of a project. A security control can produce accessibility harm; an analytics feature can create privacy risk; an AI feature can alter procedural fairness. Early interdisciplinary review produces better technical and institutional outcomes.

8. Challenges and Limitations

No checklist guarantees responsible design. WCAG conformance cannot capture every disability or context. Automated security scanners miss business-logic flaws and supply-chain compromise. Privacy notices may be legally complete yet unreadable. Ethical review may be weakened by organizational power, deadlines, or incentives that reward engagement over user welfare. User research can also exclude people if recruitment, compensation, or research materials are inaccessible.

Trade-offs should therefore be documented with assumptions, affected groups, residual risk, decision owners, and review dates. When risks concern safety, discrimination, financial loss, or sensitive data, teams should prefer reversible experiments, independent review, and conservative defaults.

9. Best-Practice Checklist

• Use semantic HTML before adding ARIA; use ARIA only when semantics are insufficient.
• Preserve logical focus and announce meaningful asynchronous changes.
• Test critical journeys with keyboard users and assistive technologies.
• Treat all browser data and client-side checks as potentially manipulable.
• Validate, authorize, rate-limit, and audit operations on the server.
• Avoid raw HTML rendering and manage dependencies as part of the threat model.
• Keep secrets and unnecessary personal data out of frontend bundles, URLs, logs, and analytics.
• Offer clear, reversible, non-manipulative privacy choices.
• Provide explanations, human review, and appeal for high-impact automated decisions.
• Include affected users in design, testing, governance, and post-release evaluation.

Chapter Summary

Responsible frontend development requires an integrated view of accessibility, security, privacy, and ethics. Accessibility is grounded in perceivable, operable, understandable, and robust interaction, supported by semantic HTML, correct focus management, accessible forms, and combined automated and human testing. Security depends on recognizing the browser as untrusted, enforcing authentication and authorization on the backend, preventing XSS and CSRF, securing sessions, and controlling dependency and supply-chain risk. Privacy requires data minimization, purpose limitation, transparent and meaningful consent, appropriate retention, and lifecycle governance. Ethical design extends these practices by examining autonomy, harm, justice, explainability, accountability, and the effects of persuasive or AI-assisted interfaces. React and Vue offer useful abstractions but cannot replace engineering judgment, user participation, server-side controls, or institutional accountability.

Key Terms

Accessibility: The extent to which people with diverse abilities can use a system effectively.

ARIA: Attributes that communicate semantics and states to assistive technologies when native HTML is insufficient.

Authorization: The process of determining which actions an authenticated subject may perform.

Cross-site request forgery (CSRF): An attack that induces a user’s authenticated browser to perform an unwanted state-changing request.

Cross-site scripting (XSS): Injection of attacker-controlled content that executes as script in a user’s browser.

Dark pattern: An interface design that manipulates users toward choices they may not freely or knowingly prefer.

Data minimization: Collecting and processing no more personal data than is necessary.

Differential privacy: A formal framework for limiting the privacy impact of an individual’s participation in statistical data release.

Focus management: Deliberate control of keyboard and assistive-technology focus during interaction changes.

Least privilege: Giving an identity, process, or component only the permissions required for its purpose.

Privacy by design: Integrating privacy protections into system design rather than adding them after implementation.

Purpose limitation: Restricting data use to specified, legitimate purposes.

POUR: The WCAG principles of perceivable, operable, understandable, and robust.

Semantic HTML: HTML elements whose native meaning communicates structure and behavior.

Supply-chain security: Protection against risks arising from dependencies, build tools, vendors, and external services.

Threat model: A structured analysis of assets, actors, attack paths, impacts, and mitigations.

WCAG: Web Content Accessibility Guidelines published by the World Wide Web Consortium.

XSS sanitization: Context-appropriate removal or neutralization of unsafe markup before rendering.

Review Questions

Short Answer Questions

1. Why is a client-side route guard insufficient for authorization?
2. State the four POUR principles of WCAG.
3. What is the purpose of an accessible form error association?
4. Why should sensitive identifiers generally be excluded from URLs and analytics events?
5. Distinguish authentication from authorization.

Long Answer Questions

1. Explain how semantic HTML, focus management, and live regions contribute to accessibility in single-page React or Vue applications.
2. Discuss the main frontend security threats covered in this chapter and evaluate suitable controls for each.
3. Explain privacy by design using data minimization, purpose limitation, retention, transparency, and user control.
4. Analyze how dark patterns conflict with autonomy and meaningful consent.
5. Design an integrated development and governance process for a high-impact frontend application.

Analytical / Application Questions

1. A Vue application stores a bearer token in local storage, renders user comments with v-html, and hides administrator controls from ordinary users. Identify the risks and propose a prioritized remediation plan.
2. A health application wants to collect precise location, continuous interaction analytics, and disability information to personalize services. Evaluate the proposal using privacy, accessibility, security, and ethical principles.
3. Design a testing strategy for a React payment journey that must support keyboard users, screen readers, mobile devices, fraud controls, privacy obligations, and secure authorization. Justify the order and scope of your tests.

Multiple Choice Questions with Answers

Question 1

Which statement best describes authorization?

A. Proving a person’s identity

B. Determining which actions an authenticated subject may perform

C. Encrypting data during transmission

D. Displaying a login form

Correct Answer: B. Determining which actions an authenticated subject may perform

Question 2

Which WCAG principle requires content and controls to be usable through available input methods, including keyboard interaction?

A. Perceivable

B. Operable

C. Understandable

D. Robust

Correct Answer: B. Operable

Question 3

Why is hiding an administrator button in a React interface not a security control?

A. Hidden buttons always cause XSS

B. Users cannot inspect frontend code

C. A user can bypass the interface and call the API directly

D. CSS cannot hide buttons reliably

Correct Answer: C. A user can bypass the interface and call the API directly

Question 4

Which practice most directly reduces XSS risk when displaying ordinary user text?

A. Rendering it through a native text interpolation mechanism that escapes content

B. Storing it in local storage

C. Making the text bold

D. Disabling keyboard navigation

Correct Answer: A. Rendering it through a native text interpolation mechanism that escapes content

Question 5

Which attribute prevents JavaScript from reading a session cookie?

A. Secure

B. SameSite

C. HttpOnly

D. Public

Correct Answer: C. HttpOnly

Question 6

Which choice best exemplifies data minimization?

A. Collecting every available user attribute for future use

B. Collecting only the information necessary for the stated feature

C. Keeping all data indefinitely

D. Sending full form contents to analytics

Correct Answer: B. Collecting only the information necessary for the stated feature

Question 7

What is a key requirement for an accessible modal dialog?

A. It must remove all visible labels

B. It should move focus predictably into the dialog and manage focus while open

C. It must always use a full page reload

D. It should prevent Escape from closing it in every situation

Correct Answer: B. It should move focus predictably into the dialog and manage focus while open

Question 8

Which practice is an example of a dark pattern?

A. Providing a clearly labeled opt-out button

B. Using semantic headings

C. Making cancellation difficult while making subscription easy

D. Providing a keyboard-accessible dialog

Correct Answer: C. Making cancellation difficult while making subscription easy

Question 9

Why is client-side validation insufficient for business-rule enforcement?

A. Browsers cannot display error messages

B. Client code can be modified or bypassed

C. Validation prevents accessibility testing

D. Servers cannot validate input

Correct Answer: B. Client code can be modified or bypassed

Question 10

Which ethical principle primarily concerns fair distribution of benefits and burdens?

A. Justice

B. Autonomy

C. Robustness

D. Confidentiality

Correct Answer: A. Justice