Addressing reviewer feedback on blocking issues

Author: msjasteppe

articles/healthcare-apis/azure-api-for-fhir/disaster-recovery.md

@@ -33,29 +33,29 @@ By default, Azure API for FHIR offers data protection through backup and restore
 
 It's worth noting that the throughput RU/s must have the same values in the primary and secondary regions.
 
-[![Azure Traffic Manager](media/disaster-recovery/azure-traffic-manager.png)](media/disaster-recovery/azure-traffic-manager.png#lightbox)
+[![Screenshot of Azure Traffic Manager.](media/disaster-recovery/azure-traffic-manager.png)](media/disaster-recovery/azure-traffic-manager.png#lightbox)
 
 ### Automatic failover
 
 During a primary region outage, the Azure API for FHIR automatically fails over to the secondary region and the same service endpoint is used. The service is expected to resume in one hour or less, and potential data loss is up to 15 minutes' worth of data. Other configuration changes may be required. For more information, see [Configuration changes in DR](#configuration-changes-in-dr).
 
-[![Failover in disaster recovery](media/disaster-recovery/failover-in-disaster-recovery.png)](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
+[![Screenshot of failover in disaster recovery.](media/disaster-recovery/failover-in-disaster-recovery.png)](media/disaster-recovery/failover-in-disaster-recovery.png#lightbox)
 
 ### Affected region recovery
 
 After the affected region recovers, it's automatically available as a secondary region and data replication restarts. You can start the data recovery process or wait until the failback step is completed.
 
-[![Replication in disaster recovery](media/disaster-recovery/replication-in-disaster-recovery.png)](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
+[![Screenshot of replication in disaster recovery.](media/disaster-recovery/replication-in-disaster-recovery.png)](media/disaster-recovery/replication-in-disaster-recovery.png#lightbox)
 
 When the compute has failed back to the recovered region and the data hasn't, there may be potential network latencies. The main reason is that the compute and the data are in two different regions. The network latencies should disappear automatically as soon as the data fails back to the recovered region through a manual trigger.
 
-[![Network latency](media/disaster-recovery/network-latency.png)](media/disaster-recovery/network-latency.png#lightbox)
+[![Screenshot of network latency.](media/disaster-recovery/network-latency.png)](media/disaster-recovery/network-latency.png#lightbox)
 
 ### Manual failback
 
 The compute fails back automatically to the recovered region. The data is switched back to the recovered region manually by the Microsoft support team using the script. 
 
-[![Failback in disaster recovery](media/disaster-recovery/failback-in-disaster-recovery.png)](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
+[![Screenshot of failback in disaster recovery.](media/disaster-recovery/failback-in-disaster-recovery.png)](media/disaster-recovery/failback-in-disaster-recovery.png#lightbox)
 
 ## Configuration changes in DR